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
- Angular Testing Part 3: Testing Recipes helps you to write tests for AngularJS controllers, services, and directives. I know from experience that is very easy to figure out excuses for not writing tests for frontend code (especially if you are a "backend developer"). However, since you have to start doing it sooner or later, you might as well do it sooner. You can get started by reading this blog post. Also, remember to read the first and second part of this tutorial as well.
- Code coverage with Gradle and JaCoCo describes how you can create code coverage reports with Gradle and JaCoCo (If you are using Maven, check this blog post). A word warning though: code coverage is a horrible way to measure the quality of your test suite. Don't use it for that purpose. However, if you need to identify the parts of your application that aren't tested properly, code coverage can help you to achieve this goal.
- How a Smell in the Tests Points to a Risk in the Design describes how a duplicate method parameter can identify a problem found from the design of the tested code. This was the first time when I heard about this idea. It is is a shame because when you think about it, it does make sense.
- Writing Unit Tests With Spock Framework: Introduction to Specifications, Part Two describes the structure of a feature method and helps you to write your first feature methods. If you are tired of writing test code with Java, you should take a look at Groovy and Spock Framework. This blog post will help you to get started.
- Mocking HTTP Interaction with Java, JUnit and MockServer describes how you can mock HTTP responses by using JUnit and MockServer. This an extremely useful technique if you need to isolate the tested code from an external API. However, you should use this technique with care because these tests won't help you catch bugs caused by the changes made by the API provider.
- Use JUnit’s expected exceptions sparingly is almost a legendary rant by Lukas Edes (the creator of jOOQ). I almost agree with him (I use the @ExpectedException annotation sometimes), but I think that he has one very important point: if all tests of a project uses the same approach, it is very likely that the author of the project thinks that it is the best way to write them. Should you try to change her/his mind? You can, but the odds are that you are just wasting everyone's time.
The Really Valuable Stuff
- Assisting with inquiries: Part one – your audience is an extremely important blog post that helps you to share information with the stakeholder of your software project. It helps you to divide these people in different groups and create a tailored message for each group. Originally I thought that this tutorial talks about testing, but when I was reading this blog post, I realized that you must use this approach every time when you communicate with people. I urge that you do your colleagues a favor and read this blog post.
- Cucumber is NOT a testing framework! is an interesting blog post which argues that Cucumber is a specification tool. Last week a colleague of mine said that Robot is a testing framework, and I agreed with him. However, when I was reading this blog post, I realized that a specification and an automated test (or a check) are two very different things. Why? If you want to find out an answer to that question, you should read this blog post.
- Testing myth #1: Writing tests slows you down is an important post that explains that writing tests slows you down only if you think about short term costs (i.e. you want to get this shit done as fast as possible), you haven't written a lot of tests, or you write your tests on the wrong level. I agree. If you don't write tests for your code, you are doing a huge disservice to the poor soul who have to maintain your code in the future. Do you really want to be remembered as the person whose name is used as an identifier for shitty code?
- Outdated testing concept # 2: The holy guardian of quality crushes the myth which states that testers are responsible for product's quality. The author argues that a single person (developer, tester, or a manager) cannot be responsible for the quality of the end product. Instead he proposes that: "Everyone adds value with his own unique skills to the product and bears the responsibility for the consequences of his mistakes". It is hard to disagree with that, and to be honest, I don't even want to.
- Understanding How To Do Accessibility Testing is a blog post that made me feel (a bit) ashamed of myself. The reason why I reacted this way is that no one has ever done accessibility testing for the software that was written by me, and this blog post reminded me of the fact that this probably means that there are people who simply cannot use "my software". It would be quite easy to say: "It is not my fault because...". I won't do this because I want to be proud of my work and blaming other people won't help me to achieve this goal. Instead I decided to learn more about about accessibility. Where should I start?
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.