TL;DR  [expand = „Click here to see short summary”]

  Good Book! It will help you shape how to think about writing code, even for test automation.

[/expand]

A struggle for quality

When I have started my adventure with test automation, my team w was treating test code as second class. It neither needed to go through code reviews nor had to follow any standards. As long as it was working and finding some bugs they were happy.

But I realized fast how important is a good quality of code. It is easier to add new features (or in our test new tests) and easier to find what broke.  Writing great quality code is not easy it requires knowledge. Knowing your toolbox is not enough. You need to know how to write good quality code. And I definitely wish I have read this book beck then.

'Clean Code’ is not for beginners, that just learned how to code and think they know better. It is for those who already got burned few times, and started to realize that it is not enough to just write the code! It needs to be good and readable. And this book will help you with writing such code. But I have to warn you. This is not an easy book, even in intro Author informs a  reader that he will have to think hard to get most of this book.

Syntax highlight

And he is right! Nearly every page has at least some snipped of code sometimes 4-5 pages long.  I have read code in books few times, but never before it was so taxing as in this book. The challenge comes it snippet is important and demonstrates some principle.  You can’t just gloss over you need to know it. Otherwise, when Martin starts to explain what is wrong and how to fix it, you won’t understand.

An extra difficulty comes from a code being only preformatted. I never missed color highlighted syntax as much as while reading this book.

Just to prove my point here you have a code snippet I wrote some time ago:

 [TestMethod]
 public void CheckoutPage_PaymentSection_PayPalAvailable_VerOne()
 {
 
 var loginPage = new LoginPage(driver);
 loginPage
 .InsertLogin(login)
 .InsertPassword(password)
 .ClickLoginButton();

 var storeFront = new StoreFrontPage(driver);
 storeFront.SelectFirstProduct();

 var productPage = new ProductPage(driver);
 productPage
 .ClickAddProduct()
 .ClickGoToCart();

 var checkoutPage = new CheckoutPage(driver);
 Assert.IsTrue(checkoutPage.IsPayPalAvailable());
 }

Something fills not right and it is only due missing syntax coloring.

[csharp]

[TestMethod]
public void CheckoutPage_PaymentSection_PayPalAvailable_VerOne()
{

var loginPage = new LoginPage(driver);
loginPage
.InsertLogin(login)
.InsertPassword(password)
.ClickLoginButton();

var storeFront = new StoreFrontPage(driver);
storeFront.SelectFirstProduct();

var productPage = new ProductPage(driver);
productPage
.ClickAddProduct()
.ClickGoToCart();

var checkoutPage = new CheckoutPage(driver);
Assert.IsTrue(checkoutPage.IsPayPalAvailable());
}

[/csharp]

Now this is much better don’t you agree? While reading this book I had an impression that it would be better as some interactive online course.  [expand]And I think so does author cause he have created this: https://cleancoders.com/ [/expand]

Structure

Book is separated into two parts + two appendices

The first part consists of 13 chapters. Where Author explains in-depth different factors, their importance and how to apply them.  Those are great fundamentals! Try this: After each chapter open your code. Each time you will see more and more things to correct.

Then comes second part. Basically, it consists of 3 cases studies and a list of useful ideas for refactoring. This part is much harder. Especially since code blocks are bigger and more frequent. One of the appendices, 52 pages of source code, is used in this exercises.  But it shows good template about how to do look for smells in your code.

Is it useful for Writing Test Automation?

Just to have it out of the way, when we are writing code even for automation we are developers. So yes this book is for us.  An Author himself is saying that Test code is not a second class citizen. To be fair he meant Unit Test but we can stretch this definition to whole test code.

Although I must admit there are some points that are difficult to do in case of test automation. Especially if we are talking about UI test

Few examples:

Robert suggests running tests after each change.  – And I completely agree but UI tests are often long so running a whole suite is impossible. My solution is to first check what test are affected and run only that sub-suite. Which I admit is not a solution for every project I had to work with.

Another thing is his rules for unit test. Most of them should be kept in mind while working on test automation. But some shouldn’t uphold so strictly – His rule of One Assertion per test.  I have a similar principle.  But in the case of the UI tests, it is not always valid. Sometimes more assertion is a lesser evil. When an alternative is 10 test that going through the website to check one small thing.  In our case time is much more limited resource than in unit tests.

Where to buy.

Book is available on both Amazon and Kobo (Disclaimer – I am tester in Kobo)
Edit 05-03-2018 I am no longer tester at Kobo but I still have good memories from that place