I did something like this for a protocol I am using. The protocol has three ... well I will call them modes. The device I'm talking to supports three of them : MODE2, MODE3 and MODE5. Each of these modes uses five registers, A, B, C, D and E. I ended up with ( but did not start with ) a map for each the models which looks up the register addresses for A,B,C,D and E. The construction of this map ended up by assuming that the offsets of the addresses for A,B,C,D and E are the same for each mode. In other words only the base address of the registers changes from mode to mode, not the offsets from the base address. This assumption was hard coded into my code as I generalised from MODE2 to MODE3, and the assumption was valid as I made that transition.
The problem came with MODE5. The offsets were not the same as for MODE2 and MODE3. In fact, for MODE5, the registers are in a different order - it's not A,B,C,D,E, it's actually A,D,C,B,E. At this point, I have a problem. I know that if I write a test for MODE5, it will fail, because I have "incorrectly" generalised from the similarity between MODE2 and MODE3. But ... my company is designing this device. Frankly I just think this is a bug. I believe that my generalisation is correct and that this bug should be fixed by the people who are designing the device.
Should I :
(i) degeneralise ( ie complicate ) my code and write a working test for MODE5 ?
(ii) write a failing test for MODE5 ?
(iii) not write any test for MODE5 ?
[ Apologies for not using TDD as you can see from my question - but I think the question could be rephrased in TDD terms ]
This is a really interesting case, and I think there may be other options (apologies if I suggest things that are impossible or infeasible, as I don't know your domain!):
a) Write an adapter for MODE5 that translates it so that it looks like the others?
b) Decouple the mappings (?) so that they become reusable strategies, and have a configuration table that connects modes with strategies?
I would definitely write tests for each strategy though :-)
I asked the product owner whether this was a bug or a feature. They told me that no customer has ever used or even requested MODE5. Since there is no business value in writing any code relating to MODE5, I have deleted all my MODE5 code. Which gave me great pleasure.
There is a part of pushing assumptions away that I found most challenging, which is how both the consumer and the producer interact to define a contract. For example, the consumer has opinions on the fact that a URL must be provided in the response, but the fact that the producer is located elsewhere (and reachable through HTTP) implies that a Promise needs to be used while adding all sort of possible error conditions.
I love how other people think about how their code and process works - this is really interesting, thanks for sharing - love it!
Thanks Paul, much appreciated!
I did something like this for a protocol I am using. The protocol has three ... well I will call them modes. The device I'm talking to supports three of them : MODE2, MODE3 and MODE5. Each of these modes uses five registers, A, B, C, D and E. I ended up with ( but did not start with ) a map for each the models which looks up the register addresses for A,B,C,D and E. The construction of this map ended up by assuming that the offsets of the addresses for A,B,C,D and E are the same for each mode. In other words only the base address of the registers changes from mode to mode, not the offsets from the base address. This assumption was hard coded into my code as I generalised from MODE2 to MODE3, and the assumption was valid as I made that transition.
The problem came with MODE5. The offsets were not the same as for MODE2 and MODE3. In fact, for MODE5, the registers are in a different order - it's not A,B,C,D,E, it's actually A,D,C,B,E. At this point, I have a problem. I know that if I write a test for MODE5, it will fail, because I have "incorrectly" generalised from the similarity between MODE2 and MODE3. But ... my company is designing this device. Frankly I just think this is a bug. I believe that my generalisation is correct and that this bug should be fixed by the people who are designing the device.
Should I :
(i) degeneralise ( ie complicate ) my code and write a working test for MODE5 ?
(ii) write a failing test for MODE5 ?
(iii) not write any test for MODE5 ?
[ Apologies for not using TDD as you can see from my question - but I think the question could be rephrased in TDD terms ]
Hi Adam,
This is a really interesting case, and I think there may be other options (apologies if I suggest things that are impossible or infeasible, as I don't know your domain!):
a) Write an adapter for MODE5 that translates it so that it looks like the others?
b) Decouple the mappings (?) so that they become reusable strategies, and have a configuration table that connects modes with strategies?
I would definitely write tests for each strategy though :-)
I asked the product owner whether this was a bug or a feature. They told me that no customer has ever used or even requested MODE5. Since there is no business value in writing any code relating to MODE5, I have deleted all my MODE5 code. Which gave me great pleasure.
That's a big win Adam!
There is a part of pushing assumptions away that I found most challenging, which is how both the consumer and the producer interact to define a contract. For example, the consumer has opinions on the fact that a URL must be provided in the response, but the fact that the producer is located elsewhere (and reachable through HTTP) implies that a Promise needs to be used while adding all sort of possible error conditions.
Ha, testing across a HTTP boundary might have to be a subject for another time 🙂