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
- How to Replace Rules in JUnit 5 helps you to replace JUnit 4 rules with JUnit 5 extensions. This post describes how you can rewrite two existing rules (ConditionalIgnoreRule and TemporaryFolder) to use the extension model introduced by JUnit 5. I like this post because it is well-written and it demonstrates how easy it is to fix the mistakes made in the past (assuming that you use JUnit 5).
- How to verify equality without equals method helps you to ensure that two objects contain the same data. It is quite easy to write assertions that do this, but this solution requires more than one line of code. If you want to find out how to do this by using only one line of code, you should read this blog post.
- Introducing FluentLenium (2) - Selenium waiting game describes how you can write readable end-to-end tests, which wait for a specific element to appear, by using a Selenium extension called FluentLenium. Whether you like it or not, waiting for elements to appear is very common if you are writing end-to-end tests for modern web applications. That is why I think that you should take a look at this blog post (and FluentLenium).
The Really Valuable Stuff
- Going back to where we once went wrong explains why you should not use the term regression testing when you are talking to your customers. It also introduces a better term that helps to manage the expectations of your customers. What term is that? Well, if you want to find out an answer to that question, I suggest that you read this blog post.
- Recovering a broken test suite tells a story of a developer (the author) who joined a new project and found out that their existing "test suite" is worthless. It also describes how the author started the recovery process that aimed to get the situation under control. I love this post because I have been in the same situation, and I know that it takes courage to change the status quo. Also, I am really proud of the author because he didn't play the blame game. Instead he decided to help the other developers to write automated tests. That was definitely the right call.
- Repetition in testing explains why all repetition is not bad and should not be replaced with automated checks. When I read this blog post, I became angry to developers (including myself) and other test automation zealots because the currency example helped me to realize that are two problem domains that aren't most likely covered by proper automated checks: handling date and information and dealing with money (especially different currencies). Thus, I think that developers would benefit from using the techniques described in this blog post.
- Start From Scratch vs. Old Test Documentation explains why you shouldn't use old test plans (or other documents) for planning testing activities that you have to do right now. This post made me think about old automated tests that are broken because no one wanted to maintain them. To be more specific, I started to wonder why they were not removed. What is the point of leaving broken code into your version control system? Just get rid of your broken test suite and start from the beginning.
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.