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.
- Assuring Architectural Rules with ArchUnit is an interesting post that describes how you can write automated tests which enforce architectural rules.
- Introduction to Spock Specifications is a free sample lesson of my Test With Spring course. It identifies the building blocks of a Spock specification class, helps you to create your first Spock specification, and describes how you can use instance fields and fixture methods.
- Introduction to Feature Methods is a free sample lesson of my Test With Spring course. It identifies the building blocks of a Spock feature method and describes how you can use these building blocks when you write feature methods.
- Mocking HTTP, Mockito style describes how you can create a mock HTTP server with Hoverfly Java and ensure that the mock server received all expected HTTP requests.
- MySQL infrastructure testing automation at GitHub is a very interesting post that describes how Github uses automated tests for ensuring that their MySQL infrastructure is up and working as expected.
The Really Valuable Stuff
- ROI of Less Automation is a rare and a valuable blog post that identifies three benefits of having less automated tests.
- Should developers verify their own bug fixes? identifies the pros and cons of a "process" where a developer is responsible for verifying their own bug fixes. I have to admit that this is a bit confusing question because I have always assumed that it's my responsibility to verify that my bug fix actually fixes the bug before I commit any code to the version control system. To be honest, it feels ridiculous (and a bit unprofessional) to outsource this responsibility to someone else.