Developers should be prepared to use TDD. The first step is to prepare your workstation, tools, and environment.
At this moment I am developing into C# mostly, so I’m going to show you mine preparations.
When tests run slowly nobody will use them. Assume for now that we have fast tests suite. What else can slow down development?
How tests are executing.
Average word per minute for a programmer is around 70, define word length equals 5 and math gives 70*5/60/1000 = 0.0058 char/ms. It’s 1 char per 200 ms. I’m using CTRL+’ for executing tests, so, two keys cost 400 ms.
There’re in average 2 to 3 seconds for doing the same thing in IDE with a mouse, you know, move a cursor, one or two clicks.
Calling tests 30 times per working day:
Hotkey – 400*30=12000 ms=12 s
Mouse – 3000*30=90000 ms=90 s
Run tests by a hotkey. Use same hotkey in any IDE.
In JetBrains Rider open settings and assign a hotkey for run tests in the current scope and run current session.
Run Unit Tests run tests in the current scope. The scope depends on a cursor position, so if the cursor in a test method, it will run only that method. If in a test class but not in the method then all tests within the class will be called.
Run Current session run tests from the current session. All solution tests are in current session by default. Rider allows creating custom sessions. One good thing about sessions that a programmer can have one session for fast Isolated Unit tests and another session for Integration tests which can be slow.
In VSCode press CTRL+SHIFT+P -> Preferences: Open Keyboard Shortcuts File.
In keybindings.json you’d have a JSON array. Add
It means to call a task named test when pressing CTRL+’. Also, need to create a task with test name in a project.
Below an example for .NET Core project.
Install .NET Core. Make sure that CLI dotnet commands are working fine.
Make a sample directory and move into.
Hit CTRL+’ in VSCode and see that terminal is opened and 1 test passed from UnitTest1.cs file.
tasks.json should be like that.
The thing is, it doesn’t matter if you’re programming in IDE, vim or any text editor. A programmer should run test suite fast.
It’s common for a developer to forget to cover corner sides when implementing features.
Human’s short-term memory can handle no more than four information chunks. B. Oakley, A Mind for Numbers.
Better to persist chunks somewhere. Use a piece of paper or an app for it.
Think ahead and write ideas to notepad.
Write all actions related to a task, focus on it for 5-10 minutes. After defining actions, choose understandable one and start working on test cases. Write them to notepad for 5-10 minutes. Choose simplest test case – it’s a kernel. Kernel drives other test cases. Split test cases into two sets and extract new action if there’s more than one kernel.
Write a test for the kernel, make him pass and cross out the kernel from notepad. Do it for a next easiest case. Notepad will show that some cases aren’t covered.
One more good thing, the notepad helps get back on track and shows unfinished work. So, a programmer can walk away from development for a lunch, go stretch, whatever, and return to development. More details in Task Interruptions in Requirements Engineering.
Interruptions are common in real life, so, when a programmer is losing focus he is spending less time on bringing back the task context when looking at the notepad. However, avoid interruptions because switching the context back and forth
comes with a price: experiencing more stress, higher frustration, time pressure, and effort. The Cost of Interrupted Work: More Speed and Stress
- Assign test suite call to a hotkey
- Think ahead, use notepad
Next week I’m going to dive into examples, see you.
J. B. Rainsberger Reintroduction to TDD