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.
- Creating stubs using the Hoverfly Java DSL provides a quick introduction to Hoverfly and describes how you can stub HTTP responses by using its Java DSL.
- Integration testing strategies for Spring Boot microservices describes why writing unit and end-to-end tests is not enough if we are serious about test automation. The solution to this problem is to write integration tests on the API level, but this can be tricky if you are using the microservice architecture. The interesting part of this blog post describes how you can solve this problem if you are you using Spring boot.
The Really Valuable Stuff
- Should I test at the GUI Level or the API Level? describes the thought process that the author uses when he decides what kind of tests he will write. This is an important post because most of the time the answer to this question is: it depends. However, asking the “correct” questions will help you to make better decisions, and this blog post identifies questions that are worth answering.
- Software Testing Guiding Principles identifies 11 “guiding principles” of software testing and describes how these principles help you to become a more effective member of your team.
- Sun Tzu Was a Tester?? takes 22 quotes from the Sun Tzu’s famous book The Art of War and explains how these quotes can be applied to testing. If you decide to read this blog post, you will notice that The Art of War is a quite versatile book.
- Test Trade-Offs is an interesting post that identifies the problems of the traditional test pyramid and introduces the test trade-offs models that helps you to decide what kind of tests you should write. This model has three dimensions (speed, coverage, and variation), and its main idea is that every test must “sacrifice” some of the dimensions so that it can fulfill its goal.