Systems that aren’t testable aren’t verifiable. Arguably, a system that cannot be verified should never be deployed. — Robert C. Martin Sleep is one of the most important and healthiest things you can do for your body. It is said that good sleepers have better concentration and productivity, isn’t that what we are all aiming for? I have been producing code for almost ten years now and I have seen and written tons of smelly, spaghetti code. Testing allows me to sleep well at night and that is why I want to share my thoughts and practices about it. Start writing tests Writing tests should be an integral part of our daily duties as you consider yourself professional software engineer. If this sounds new to you, please . Trust me. I was in your boots and I know how hard is to kick off but in fact, it is easier than you think. In the beginning, you will feel a little bit disappointed because it will perturb your productivity but I can assure you that “test investment” pays off sooner than later. In addition, over time you will become more confident and a faster engineer in test. start testing your code from today Treat tests like your codebase Almost all software engineers I have met know who is Robert C. Martin. He is a clean code evangelist and the author of amazing books and articles that changed our way of thinking about software development. Nowadays there is a lot of buzz about code refactoring, code readability, and code conciseness so why are you not applying this knowledge to your tests? People tend to draw a strong line between code and tests but for me, there is no difference and I see them as siblings. That is why caring about readability, conciseness, and usefulness. DRY and SOLID testing! I treat my tests like I treat my codebase Document code through tests Documentation is always a big pain because of hardness in maintaining it, and additionally, it is often outdated. In my opinion, the code has to be self-documented by being clear, simple, and having a full suite of tests. I always try to make my as as it is possible . It is a hidden benefit of testing that every software engineer should be aware of. tests readable to provide the best documentation for my code Make them fail If there are no failing tests every now and again, it is a sign that you are not doing them right. It is a very good practice to write tests first but this is not what I mean. if setup works as incorrect mocking can make your weak. Fail them to check your assertions and verifications Happy path is not enough The is the code covered with tests as they give an illusory safety. Designing robust and reliable test cases is the hardest and the most satisfying part of my daily duties. To make it more interesting take your craft to extreme and use test driven development and pair program with your colleagues. worst thing “happy path” Do not change code to write tests This point is crucial in conjunction with architecture and security so it should be as important as your date of birth. Think twice while breaking an encapsulation to test your code because . Actually, this kind of situations is always pointing on bad design. I made this mistake and in most cases, I ended up rewriting components from the scratch. the leaking architecture will slow down your work in the future Be careful with test doubles Simply do not misuse test doubles as they can lead to non-obvious . When implementation details in your production code change, you will have to refactor your tests to reflect these changes. Moreover, tests will become because of huge setups. implementation leak less readable and maintainable Review test cases Code review is the best tool to examine pre-production code and find bugs in it. Lately, I was interviewing a couple of engineers and I noticed that their code reviewing skills were terribly neglected. Most of them do not even try to open a test class to check what is inside, scary right? Personally, I love to and I always investigate them first. I use built-in code coverage tool in IntelliJ to check “Hits”. Too many or too little of them can tell you if the code is over or under covered. review test cases Test picked up use cases Reading and understanding someone else’s code is our daily routine. Do you know that feeling when you have to change the non-tested code? During it you research repository, talk to other programmers, make notes and then you apply changes. There is one step missing in that chain. Before changing the code you should . Also, you can use “characterization testing” against an existing code to understand the logic behind it. write the test to every single use case that you picked up Try different frameworks It is not just that software engineers fear new , though they undoubtedly do. It is also that they truly believe that when you have been doing something a particular way for some time, it must be the best way to do it. I notice a strong tendency in world to use JUnit as a main tool to write unit tests despite the fact that it has a lot of pitfalls. I use Spock in exchange for JUnit to apply robust Groovy syntax to my tests and it works like a charm. There are many , great like TestNG and the latest Spek that . tools Java other frameworks can help you to achieve conciseness and readability Be pragmatic With growing skills hunger accelerates rapidly, and to feed it you try to test everything. Remember that the more tests you write, the more code you have to maintain. code such as getters, setters, constructors etc. Being pragmatic will stop you from testing boilerplate Summing up, I hope that you have found some helpful bits of advice or at least I inspired you enough to start working on your own best testing practices. If this was interesting to you, please do hit the heart button ❤ or let me know on Twitter .

Chain

Routine

Twitter

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Test well, sleep well

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

Piotr Ślesarew

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Test well, sleep well

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

Piotr Ślesarew

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES