There are many software development blogs out there, but many of them don't publish testing articles on a regular basis.
Also, I have noticed that some software developers don't read blogs written by software testers.
That is a shame because I think that we can learn a lot from them.
That is why I decided to create a newsletter that shares the best testing articles which I found during the last week.
Let's get started.
Technical Stuff
- Effective assertions, from Java to Scala starts by describing the brief history of different assertion styles that are found from (J)Unit tests and provides a quick glimpse into the future by taking a look at different assertion libraries that can be used for writing unit tests for Scala code. I think that this blog post is extremely fascinating because I have followed the same path as the author and reading this blog post brought back a lot of (probably embarrassing) memories.
- FitNesse in your IDE announces the release of Fitnesse plugin for IntelliJ Idea. Fitnesse was created by Uncle Bob in 2001, and apparently this is the first IDE plugin that supports Fitnesse. This sounds a bit crazy to me. Anyway, if you are using Fitnesse and IntelliJ Idea, you should take a look at this plugin.
- Introduction to Spring REST Docs describes how you can document your REST API by writing integration tests with Spring Test MVC. This blog post provides the information you need to get started with Spring Rest Docs, and it has a working example application as well. By the way, if you are using Rest-assured, you are probably happy to hear that Spring Rest Docs will support it in the future.
- Robot Framework and the keyword-driven approach to test automation - Part 2 of 3 provides a comprehensive introduction to Robot keywords, identifies the risks of keyword-driven testing, and helps you to avoid these risks. I like this tutorial because it describes the "theory" behind keyword-driven testing before it shows how you can actually do it. This will help you to evaluate whether or not keyword-driven testing is useful to you. Also, if you decide to read this post, you should probably read the part one of this tutorial before you read this blog post.
The Really Valuable Stuff
- Agile Testing: Frustrations can make us creative answers to these two questions: 1) Who should do manual testing in an agile team? 2) When should this testing take place? These are important questions and I think that we (developers) must do our part. Actually one of my biggest problems is that I cannot work with a tester because we don't have any testers. I bet that it would be fun to pair with a tester, and figure out what kind of (manual) tests I should do for my code. Sure, I always test that my code "works", but I suck at exploratory testing. I know that I won't ever be an expert, but it would be useful to know the basics. Also, it would be interesting to get a second opinion on my precious unit and integration tests.
- Assisting with inquiries: Part three – filtering information helps you to understand why you should filter information before your report it to different audiences. The thing is that different people are interested in different things, and they will filter uninteresting information anyway. If you want to keep your message intact, you need to provide information that is relevant to your audience, and this blog post helps you to do it.
- Recovery Testing Best Practices describes why you should care about recovery testing and provides solid examples that help you to do recovery testing for real-life applications. I think that recovery testing is extremely important. Sadly, I also have a "gut feeling" which says that it is also extremely rare. However, since I am an optimistic person, I hope that this blog post motivates people to at least identify the need for recovery testing. It is not much, but it is a start.
- Testing myth #2: Unit tests are not worth it busts the myth which that states writing unit tests is not worth it. I agree with the author, and I would like to add that one potential reason why developers keep this myth alive is that they simply don't know how to write good unit tests and are too ashamed to admit it.
- What Flaky Tests Can Tell You argues that flaky end-to-end tests can reveal performance problems, bugs, teamwork problems, and communication problems. This post makes some interesting points because developers typically think that non-deterministic tests are harmful because they cause so many false alarms that developers don't trust their test suite anymore (remember what happened to the boy who cried wolf). Often non-deterministic tests are either ignored or deleted. I used to think that this is a good way to deal with them, but I changed my mind after I read this blog post. I still think that might be OK to delete them, but first we should ensure that this behavior is not caused by a bug or a performance problem.
- Who is testing your unit tests? addresses the following argument: "TDD is flawed by default, as nobody is testing your unit tests". I have to admit that even though I like this blog post, I am pretty sure that I don't like the argument. To be honest, it sounds like an excuse to not do something that the person doesn't want to do. I think the author of the post makes many good points, and I would like add my own opinion: If your tests are so complex that you need to test them, you are writing shitty tests. Split your tests into smaller tests which are more readable and contain less bugs. This will help you to write tests that specify the requirements of the system under tests.
It's Time for Feedback
Because I want to make this newsletter worth your time, I am asking you to help me make it better.
- If you have any feedback about this newsletter, share your thoughts on the comment section.
- If you have written a blog post about automated testing or software testing, ping me on Twitter.
- You can share this blog post on Twitter.
P.S. If you want to make sure that you don't ever miss Java Testing Weekly, you should subscribe my newsletter.