Earlier we had implemented a feature, but the test had a bug. Now that the test has been fixed, there is a temptation to continue when we see it pass, but that would be dangerous. It's better to revert the implementation and see the fixed test fail, to make sure that the test is working.
2010-12-28
2010-12-23
Let's Code Dimdwarf #27: Extracting ClientRunner
To be able to write a unit tests for connecting multiple clients, a helper class needs to be extracted from the existing test code.
2010-12-22
Let's Code Dimdwarf #26: Avoid Rushing
The temptation to make the end-to-end test pass is high, but it's better to slow down and first write some unit tests for the feature. Otherwise the unit test coverage, which is the basis for enabling refactoring, would not be complete. Maybe a rule of thumb would be: "If end-to-end tests fail, but unit tests pass, you need more unit tests."
2010-12-15
Let's Code Dimdwarf #25: Return to Sender
Something funny is happening. The messages from the network layer are being returned to sender. We also organize the packages a bit and proceed to the next step of the ongoing refactoring.
2010-12-12
Let's Code Dimdwarf #24: Merging Classes for Higher Cohesion
When a responsibility of doing something is spread over many classes, it becomes harder to understand and modify. In such a situation the responsibilities should be moved or classes merged, so that all the handling of a responsibility is in one highly cohesive place.
2010-12-10
Let's Code Dimdwarf #23: Refactoring Driven by End-to-End Tests
Between each step of our refactoring, all our unit tests pass, but the end-to-end tests don't. This situtation is possible when the components and their unit tests are so well decoupled (due to using message passing) that changing one component does not affect other components - until they are plugged together. We use the end-to-end tests to drive the refactoring, by fixing components in the order that they fail, until the refactoring has been done to all of them.
2010-12-08
Let's Code Dimdwarf #22: Preparatory Refactoring
This episode starts a new arc - implementing support for more than one concurrent client. First we need a reproducable, failing end-to-end test. Also before being able to add support for multiple clients, some preparatory refactoring1 is needed: wrap the messages from clients into a class, to which we can then easily add a client session handle.
1 The word prefactoring has already another meaning, so maybe this is "pre-refactoring"? Do you have better ideas for a word?
Subscribe to:
Posts (Atom)