Hi,
In this tiny article I am going to discuss about testing. This article will not focus on the definition of TDD (Test-Driven-Development) because you can find a considerable amount of articles on the internet about WHAT it is but rather my goal is to cover some aspects not so well-covered such as how to start in an environment with no culture of testing based on my experiences.
In other words: How to convince your boss (assuming that he/she doesn’t have any notion of testing) that now a story needs to be delivered a few hours later because you need to write some unit tests?
About definitions: You can find the definition from people who coined this term here and here.
Getting started
Ok. Let’s assume you know what TDD is and you have some knowledge on how to write unit tests, you will probably make yourself a question: How can apply this technique within my company? One step at time, I would say. Let’s see some:
- Look for a suitable unit test framework for your language. I would recommend the following for the languages I used:
- C#: NUnit or xUnit
- Ruby: Rack or test-unit
- Java: JUnit
- It may seem obvious, but create a test project. It does not take time.
- When you pick up a task that you identify as an independent implementation from other layers, like a calculator, service, etc. and define first its interface signature. for this example I will use a sum calculator as an example. So my interface signature will be
double Sum(double a, double b);
- Create a test class inside your test project. My recommendation is to create at least a test class per interface. Inside of this class, create a test method. For the sake of this example I will use the C# NUnit syntax, because I am more used to it. I like to use the following naming convention:
[method]_should_[expected behavior]
[Test]
public void Sum_Should_ReturnSumOfTwoNumbers()
{
// Arrange
var myClass = MyContainer.Resolve();
var a = 1;
var b = 2;
var expectedResult = 3;
// Act
var result = myClass.Sum(a, b);
// Assert
Assert.AreEqual(result, expectedResult);
}
- As you might notice, I put some comments in the example above (Arrange, Act and Assert). They are there because there is a steps pattern that I like to follow called AAA. It makes your testing code more clean and easier to read among your team. If you follow this mindset will be easier to make your tests. Basically:
- The Arrange section of a unit test method initializes objects and sets the value of the data that is passed to the method under test.
- The Act section invokes the method under test with the arranged parameters.
- The Assert section verifies that the action of the method under test behaves as expected.
- For this stage of maturity, creating one passing test per relevant function is fine. While you get more used to this, you will feel the need to create tests that also tests failing scenarios, alternative scenarios and so on.
- Just that! now for the next tasks repeat the previous steps, collect the results, improve, share. During this process you will feel more confident of what you are producing. Start from simple components and, after getting experience, go to more complex things 🙂
Testing improves:
Testing improves many aspects of your code, but out of the obvious benefits, I would emphasise the following:
- Predictability. Each scenario covered by good tests is a certainty of code working properly.
There is no other way you can be 100% sure your code works if it is not covered by some sort of tests.
- Courage. If you see a code that could be done better and it’s covered by tests, you have no fear to improve it, because after refactoring you can easily run the tests. If all of them passes your refactoring was successful.
When programmers lose the fear of cleaning, they clean! and clean code is easier to understand, easier to change, and easier to extend.
Defects become even less likely because the code gets simpler and predictable.
Sales Lopes 