2010-12-28

Let's Code Dimdwarf #28: Test the Test

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.

Download as MP4

Episode Archive

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.

Download as MP4

Episode Archive

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."

Download as MP4

Episode Archive

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.

Download as MP4

Episode Archive

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.

Download as MP4

Episode Archive

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.

Download as MP4

Episode Archive

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?

Download as MP4

Episode Archive