Practical TDD — Lesson 2Raphael YoshigaBlockedUnblockFollowFollowingJan 16Photo by bruce mars from PexelsOn the last article we did the FizzBuzz kata using TDD.
I feel like I’ve showed quite a bit of the development process without explaining some of the background concepts.
On this article I will go a few steps back, show theory and tips with examples.
Test structureAs a general rule, a test is normally composed of three stages:Arrange(given)- Set things up, prepare the dependencies, etc.
Act (When) — Action that is being testedAssert (Then) — Verify the resultWhen writing tests it’s useful to divide the tests into those steps.
For example:This will help in readability and in your mindset when writing the tests.
Comments for those divisions are for learning purposes only, do not include those in actual production code, just make the logical separation using blank spaces as:Red, Green, RefactorWhen practising TDD you will enter a cycle, you write the test, run expecting a failure, you make it pass and then you refactor it.
Visualised:TDD cycle — Image SourceTake for example my start at the StringCalculator kataString Calculator requirements:Create a simple String calculator with a method int Add(string numbers).
The method can take 0, 1 or 2 numbers, and will return their sum (for an empty string it will return 0).
For example “” or “1” or “1,2”When testing a simple scenario, that a single digit returns it’s value parsed to integer.
The process goes like this:Test that “1” returns 1, FAIL > Hard-code the condition and return 1 > PASSTest that “155” returns 155 > FAIL > Hard-code 155 > PASSTest that “9” returns 9 > FAIL > Hard-code 9 >PASSThen the code looks like this:So at this point It’s perfect for me to refactor, I got a good coverage, everything is green, refactoring gets me to:Even though in general you want to do the 3 stages as often as possible, in this case I couldn’t refactor much until I got the pattern three times before I abstracted.
Remember to try to do 3 stages, beginners in TDD tend to enter many cycles of Red>Green, Red>Green, Red>Green > massive refactor.
To counter the previous habit, I normally put devs into:The TDD clock gamePhoto by Jordan Benton from PexelsThe game is a simple race against time, the developer(s) have few minutes to think about what they are going to do next, they can choose to:Add more test cases and proceed with the implementationRefactorAs soon as they start the coding we put them on a timer, (2–5 minutes to be defined), if they decided to add more test cases, they need:To add the test, fail itImplement it so its passing.
If they don’t manage to finish in time and commit it, we do:Note the developers can only commit if the tests are passing.
This game is great to make devs think small and simple, enough to breakdown the problem into such small tasks that they can have such short iterations.
Also it denies massive refactors, because if you make a massive change, chances are you will break things and run over time.
Tests deserve to be taken care tooSometimes it happens, the 3 cycles of TDD get applied to the production code, but the test never see the refactor cycle.
The test code is just as important as the production code, it is the documentation, it is the safety net for you to refactor.
If the tests gets bloated you might just get to the point you don’t understand and trust them, so many TDD benefits are lost.
During my take on the string calculator, my tests looked like this, can you see anything wrong with it?The major thing is the duplication in the set up, for example initialising the StringCalculator.
So with Xunit we can do:For something as small as a act and assert, I wouldn’t mind not even separating them.
Bonus for .
net developersI hope until this point you have been getting into the habit of running the tests to make it fail, implement it and then run them to make them pass.
If you learn the keyboard shortcuts the pain shouldn’t be too much, but… Let me introduce you to Live unit testing:Enabling Live unit testing in visual studioLive unit testing is letting the IDE run the tests automatically every time it detects code changes.
The 3 cycles are still there, the only difference is the IDE will run the tests for you.
This is how it shows the tests are failing:Visual Studio live unit testing failing testAnd when they are passing:Visual Studio live unit testing passing testsThat can speed up your development considerably.
ConclusionOn this article I hope to give you more theory knowledge and how to apply into practice.
We covered theories in test structures, TDD cycles, important of refactoring tests and live unit testing in .
net core.
You can download the String Calculator from here.
If you are following this series, I’m happy to help you with your Katas, send me the github repositories and I can review them to see if I can give any good insights.
Cheers.
.