Chapter 4: Privacy
A benefit of TDD is having tests which document code behavior; this chapter starts by adapting an existing test to make it "speaking". We change our assertion to be based on an object of a particular value rather than a value separated from it's context and, at the same time inline some noisy declarations.
I like to use the IDE to help me refactor, so inlining the 'actual result' declaration for my AssertEquals comparison using the shortcut ⌥ ⌘ N (mac) / Ctrl+Alt+N(windows) is a joyful thing to do!
An assertion of truth, not a sequence of operations
You will only have tests which document the code if you write them in such a way they are clearly understood. As you build functionality your test suite can be improved upon, but there is inherent risk in changing tests. Relying on the TDD process should give some confidence in moving forward whilst keeping the tests green.
And with regards to privacy...? The code change in this chapter allows us to make a public instance variable private.
🔎 View my code-along repo at https://github.com/ruthmoog/test-driven-development-by-example
Top comments (2)
Thanks for your discussion Leonid!
I would say that TDD is difficult, but not impractical. If we're talking about designing new code, using TDD correctly will give you an easier to maintain codebase. A criticism I've heard which could be interpreted as impractical is that it's slow; This depends if you're writing software (malleable, long-life code) or a throwaway project. TDD involves investment, and that can be at odds with a 'move fast and break things' attitude. But maybe thats not what you mean?
Whenever you have no idea what solution you're aiming for, TDD is a perfect tool for getting to a solution IMO: The process allows you to break down a problem - firstly so that you understand the problem (if you don't understand it well enough to write a test, then more investigation into the problem that you're trying to solve is needed, otherwise, why write any code? For what purpose?) and secondly, so that it's easier to test, and the tests guide you to a working implementation of the behaviour you want.
Re the legacy code point, for sure, test coverage gives you the safety to refactor. This doesn't necessarily fit with my understanding of what TDD is though, because in that scenario the design is already done, we're simply providing coverage for the existing design? But I've seen TDD used within a legacy codebase to make changes and build features so it is possible!
The scroll tool is fun!
I'm not familiar with testing something like that, I wonder if something like Selenium WebDriver would enable TDD for such a project? and maybe building in some acceptance testing with Automated Visual Testing post-hoc. You could use BDD-style specifications to know the implemented animation is meeting your acceptance criteria (eg. yep the
rotate buttonrotates 360° while its on the display, and, yep it spins on a horizontal pivot etc etc or whatever you want to happen) - this is probably happening already? Just not in a formal way.What I would say though, is that exploring the behaviour in the browser is totally research! Spiking code too. It's your prerogative wether to scrap the working-out and test-drive the codebase, or, keep that code in your project :D