Do you want more assertions than one in your tests? Strikt comes to your rescue
Introduction and thanks:
Hello, everyone, I’m really thankful for all the courage I received from my first post, so I will try to keep writing posts to help as much as I can.
And also I am very happy that my first post was published in Android Weekly. Thank you very much Android Weekly and whoever promoted my post and I will try to keep writing the best I can.
My second post is about testing.
I’m a strong believer of TDD but I don’t think it’s the right move for every line of code you have to write, but I believe even if you don’t do TDD, you have to write tests for your code, not just for the sake of it, but to help your team to keep improving the code base you work together without breaking anything and also for yourself for whenever you have to keep scaling the code you write or you want to keep expanding the functionality.
My biggest inspirations for testing are Sandro Mancuso, Robert C. Martin (Uncle Bob), and Kent Beck. But it was hard for me to apply everything I learned from them to my day to day work as an Android Engineer.
Someone who helped me a lot to understand how to apply all that I learned about TDD to Android was Jovche Mitrejchevski
This post that I found about 2 years ago helped me believe that it’s possible to apply TDD to Android and how to do it.
I really recommend his content to whoever wants to apply TDD to Android projects.
My problem:
I finally had the chance to use TDD in not just my pet projects but in my actual job so I was super happy and I managed to apply TDD for a full big unknown feature on a new unknown project and I think I couldn’t have done that(and still kept my sanity) without using TDD.
But one limitation I noticed while doing that is that it’s really recommended to use one assertion for test ,
and even though I think it’s a really good idea, it’s slightly limiting in many Android use cases. Partly not just because of the idea, but also because this is what happens when you have 4 failing assertions:
Old test failing:
As you can see you can only check the first failing assertion and you can’t know that something else went wrong and you fix the first assertion and run the unit test again, you will see another failure and still without knowing that you have to keep doing the same many more times and it hurts even more if you had to do the same but using the CI pipeline.
Old Test Fixed
After experiencing that I thought that maybe my best alternative was to have different similar tests but having one different assertion in each test, but I really like to keep things DRY(Don’t Repeat Yourself).
My solution:
But a friend(Cody Engel) came to my rescue
and suggested to me the Strikt Library of Rob Fletcher
One of the big advantage of this library is that it lets you see the failing message of all your assertions and with a better and more understandable language.
First of all to add string to your project you have to import this: (You can also use it in your instrumented tests when you test things related to Room and your DAOs):
Here is the same example moved to Strikt, and the result of failing all four assertions:
New Test Failing
As you can see in the image, when all or any of your assertions fails you get the error log of each assertion that fails.
And as you can see the error message is more descriptive and it’s easier to read and see what failed.
The only limitation is that you can’t use it with verification so you have to use capture slots / argument captors(if you use mockito)
New Test Success
Conclusions:
After that I moved all my tests to Strikt.
I hope this is helpful to someone as helpful as it was for me. Have a nice day and have a nice coding week(hopefully in Kotlin) 😄.
