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?
2010-11-28
Let's Code Text Adventure #7-9 (end)
Here are the final episodes of Let's Code Text Adventure, where the code is refactored to be what the code wants its design to be. I clean up some primitive obsession smells and move some functionality to where it belongs.
Source Code: github.com/orfjackal/text-adventure
Download as MP4: Ep 7, Ep 8, Ep 9
Refactoring
2010-11-27
Let's Code Dimdwarf #21: Ambiguity Paid Off
The ambiguity left remaining in episode 16 has now been cleared. This ends the current undertaking and in the next episode will begin the work on supporting more than one client.
2010-11-26
2010-11-15
Let's Code Text Adventure #1-6
Here is a mini series of developing a new application. It's a text adventure game based on a homework assignment near the end of one introductory programming course.
The homework assignment said that from the students it usually takes 10-15 hours to make this application - and even then a framework for the UI, input handling and game loop was already provided (which I didn't have nor want). I was at that level 10 years ago, back in 2000, and I think that by now I have learned programming. ;)
During these first six episodes (in 2½ hours) I manage to implement the needed functionality, but it will still take a couple more episodes to clean up the code to meet my quality standards. I will post those episodes later.
Though there is some overhead in using TDD, it will pay itself back quite soon when the development progresses. I'm guessing the flipping point to be around 2 hours, so roughly the size of this application, but it would be interesting to hear some research on that.
Source Code: github.com/orfjackal/text-adventure
Download as MP4: Ep 1, Ep 2, Ep 3, Ep 4, Ep 5, Ep 6
Project Setup & End-to-End Test
Domain Logic
Text UI
2010-11-12
Let's Code Dimdwarf #20: Make It Right
A new look at refactoring AsynchronousSink. Earlier we made it work; now we try making it right.
2010-11-10
Let's Code Dimdwarf #19: Close of the Split
Coding with backspace is fun. The last half of splitting NetworkSpec requires mostly just removing the excess parts.
2010-11-09
Let's Code Dimdwarf #18: Revenge of the Hack
When you take shortcuts in implementing things, it's important to always remember them (not realistic) or at least make them fail fast, so that you would be reminded about them when they bite you. My IoHandler was not fail-fast; it had a pointless null check.
2010-11-07
Let's Code Dimdwarf #16: Valuing Ambiguity
If you don't right now know how to do something, embrace the ambiguity and leave it for later.
2010-11-06
Let's Code Dimdwarf #15: Matcher Mismatch
Before removing the duplication between two classes or methods, they should be made as similar as possible. There is a small mismatch in what the ByteSink and EventSink matchers match.
2010-11-04
Let's Code Dimdwarf #14: Covering All Corners
When I go through things which I'm about to commit, often I find out that I'm not yet ready to commit.
P.S. After a couple of productive evenings, I've piled up unedited recordings up to episode 30. So at least for now I'll speed up my release pace to reduce the WIP.
2010-11-03
Let's Code Dimdwarf #13: Assertion Error Messages
Testing error messages requires manual verification plus automatically verifying just the important parts.
2010-10-30
Let's Code Dimdwarf #12: Right Refactoring Path
Sometimes the rights steps to a refactoring are on a long and narrow path.
2010-10-27
Let's Code Dimdwarf #11: Reuse via Deduplication
We move towards a reusable utility class by eliminating the duplication between the existing classes for two different use cases.
2010-10-23
RECAP: Let's Code Dimdwarf #1-10
Recap of episodes 1 to 10, at 10 times the normal speed, with commentary. Watching this recap should make it easier to follow what is happening in the following episodes, even if you haven't had time to watch the previous episodes.
2010-10-18
Let's Code Dimdwarf #10: Add Synchronization
Now that ByteSink's synchronous tests are passing, it's time to implement the asynchronous behaviour. Unlike with EventSink, this time synchronization needs to be done manually.
2010-10-14
Let's Code Dimdwarf #9: Second Asynchronous Use Case
In order to get a reusable utility class for writing asynchronous tests, we re-implement it for another use case. After that it will be possible to extract the common parts into a reusable class.
2010-10-12
Let's Code Dimdwarf #8: Escape from Refactoring Hell
We finally figure out what was wrong in the code and manage to clean up the mess which had piled up during the last hour or so. The first draft of the asynchronous testing tool is now ready and in the following episodes we will be making it reusable.
2010-10-10
Let's Code Dimdwarf #7: Growing a Fluent API
Let's Code is back after a short pause due to the Software Craftsmanship 2010 conference earlier this week. In the concluding talk of the conference there was a fitting quote from The Mythical Man-Month, chapter 1: The Joys of the Craft
In this episode we refactor our test code by extracting a fluent API out of it, to make the test code more readable. There is some unnecessary work in re-inventing wheels, because of not being familiar with what features JUnit and Hamcrest already provide.
2010-10-05
Let's Code Dimdwarf #6: Tumbling with Exception Messages
We try to integrate with the Hamcrest library and make our utility class produce useful exception messages. I haven't written Hamcrest matchers before, so it's not clear that how to do it.
2010-10-02
Let's Code Dimdwarf #5: Asynchronous Testing Tools
In order to easier test our asynchronous system, we need some utility classes which take care of the concurrency issues. In this episode we begin writing them.
This episode can be a good "first episode" for someone evaluating his interest in this show, because here we are writing code which does not require being familiar with the system's architecture. If you like this episode, then you might want to later watch Let's Code Dimdwarf #1, where the current project and its architecture are explained, but where no code is yet written; the coding starts in episode #2.
2010-09-29
Let's Code Dimdwarf #4: Tidying Logout Tests
Logging out is now working, so it's time to improve the readability of our tests.
2010-09-27
Let's Code Dimdwarf #3: Responding to Logout
Implementing logout continues and we get very close to completing the feature. Our tests are encountering problems with asynchrony, so in a later episode we will create some utility classes to help writing those tests.
2010-09-24
Let's Code Dimdwarf #2: Let the Coding Begin
Here is the second episode of the new Let's Code series. We get started with implementing the logging out feature of the system, implementing it step-by-step as driven by our end-to-end tests. The progress is still quite slow, as it takes some time to understand what needs to be done next and to get into the flow. We anyways manage to implement support for one new network message type and get a good start on writing the next test.
You may also notice this new blog. I created it to keep the Let's Code announcements (for each new episode) separate from the articles in my primary blog. I wouldn't want those articles to be covered by a flood of weekly announcements. So please subscribe to the web feed of this new blog if you want to know when new episodes are released.
2010-09-22
Let's Code Dimdwarf #1: Introducing the Project
I'm starting a new screencast series Let's Code, where I will be recording myself developing some open source projects. This was inspired by James Shore's Let's Play TDD series and I will try doing something similar. My goal is not to teach the basics of how to do TDD, but to show how one developer does it - in the hope that something can be learned from it. Each episode will be about 25 minutes long ("one pomodoro") and I will try to release a new episode every couple of days, but no promises about that.
Links to all episodes are at www.orfjackal.net/lets-code
I will announce all episodes of the Let's Code series in this blog, so please subscribe to this blog's Atom feed to get notified about new releases.
Here is the first episode of the series. Since I'm starting with an existing code base, it takes some time explain the architecture of the project, so this episode does not yet include coding, but watching it is recommended to understand the following episodes. Implementation will start in the second episode.
If you want to see some code quickly, then episode #5 may be a good place to start. There we start writing some isolated utility classes for asynchronous tests and it doesn't require knowledge of Dimdwarf's architecture (though in my opinion those episodes dealing with Dimdwarf's features are more interesting).
Subscribe to:
Posts (Atom)