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 ?

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);
}

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);
}

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();

1. Bad 💔

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

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);
}

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