DEV Community

Cover image for Unit Tests : Writing Readable Tests
DevByJESUS
DevByJESUS

Posted on

Unit Tests : Writing Readable Tests

Hello πŸ˜„
It's me Again
Today we will finish our series about advices for great unit tests with a long post (not so long) about writing READABLE UNIT TESTS.
So Let's go

Why Readable Unit tests ?

This question is tricky in our community some people thinks that we can go without it and others think that we should go with it . But the fact is every newspaper can transmit informations where is the difference ( apart from the price ) a great newspaper take care of the design and the others just put the informations there . In development world it is some kind of same some just put their code as long as it runs it is fine , but another group thinks that make the code runs is not enough we should represent it well for the future readers, and here we are coming in the universe of CLEAN CODE. πŸ˜—

You've guess it , I am with the group about CLEAN CODE.
Ready ? So how my unit tests can be clan ?

let's start

1. Naming Unit tests

Here the pattern is quite simple , in the name of our unit tests we should be able to respond to :

  1. The name of the method being tested
    This is what Roy Osherove say :

    This is essential, so that you can easily see
    where the tested logic is

  2. The scenario under which it’s being tested
    with a sentence like this When I call method X with a null value , you notice the with a null value , we can know the scenario of our unit test.

  3. The expected behavior when the scenario is invoked
    With a sentence like this When I call method X with a null value, then it should do Y. , when we see the then it should do Y without reading the body of the unit test we can know its expected final behaviour.

2. Naming Variables

I can not go deeper in this part , i have read a great book about it The Clean Code Book
Two differents block of code , and the readability is not the same

  1. Bad πŸ’”
[Test]
public void BadlyNamedTest()
{
   LogAnalyzer log = new LogAnalyzer();
   int result= log.GetLineCount("abc.txt");
   Assert.AreEqual(-100,result);
}

Enter fullscreen mode Exit fullscreen mode
  1. Good πŸ’š
[Test]
public void BadlyNamedTest()
{
   LogAnalyzer log = new LogAnalyzer();
   int result= log.GetLineCount("abc.txt");
   const int COULD_NOT_READ_FILE = -100;
   Assert.AreEqual(COULD_NOT_READ_FILE,result);
}

Enter fullscreen mode Exit fullscreen mode

3. Separating Asserts from Actions

Again Here to be near this advice we can write our unit test with the AAA ( Arrange - Act - Assert ) Pattern , following this we can be sure that we are going to separate our actions from our asserts. Look at the code below

//arrange
var repository = Substitute.For<IClientRepository>();
var client = new Client(repository);

// act
client.Save();

// assert
mock.Received.SomeMethod();
Enter fullscreen mode Exit fullscreen mode

1. Bad πŸ’”

[Test]
public void BadAssertMessage()
{
   //some code here
    Assert.AreEqual(COULD_NOT_READ_FILE,
       log.GetLineCount("abc.txt"));
}
Enter fullscreen mode Exit fullscreen mode

This is bad because there is no separation between the Act and the Assert

2. Good πŸ’š

[Test]
public void BadAssertMessage()
{
   //some code here
   int result= log.GetLineCount("abc.txt");
   Assert.AreEqual(COULD_NOT_READ_FILE,result);
}
Enter fullscreen mode Exit fullscreen mode

Better isn't it ? πŸ˜†

You can go further with this great article

That's all ? Yes we are talking about unit tests not your production code , for production code and daily basis I recommend you again This Book

Thanks for reading 😊
By The Grace of JESUS❀️ i will write some posts for the part 4 of the Book The Art Of Unit Testing

If you want to contact me , my email : devbyjesus@gmail.com

Discussion (0)