Java Testing Weekly 43 / 2016

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

  • Aggregate Test Coverage Report for Gradle Multi-Module Project helps you to create one test coverage report that contains the test coverage results of all modules of your Gradle build.
  • Open sourcing my workshop on WireMock announces the release of an open source work that describes how you can stub HTTP based APIs with WireMock. This workshop provides slides, exercises (and answers), and Rest Assured tests which verify that created stubs are working as expected.
  • Running Integration Tests With Gradle describes how you can add new test sets into your Gradle build, ensure that both unit and integration tests use different HTML report report directories, and run your tests with Gradle.
  • Running Integration Tests With Maven explains how you can add custom source and resource directories into your Maven build, run your integration tests by using the Maven Failsafe plugin, and ignore either unit or integration tests by using Maven profiles.
  • When to use use mocks is an interesting post where the author shares his views on mocking. To be more specific, he describes situations when it is OK to use mocks instead of other test doubles.

The Really Valuable Stuff

  • Caution when using TDD’s Triangluation technique reveals a very interesting problem that is caused by TDD. This problem is: writing too many redundant tests.
  • Continuous Testing in DevOps… is an interesting post that helps you understand that continuous testing and devops can coexist together.
  • Manage your biases as a tester – Part 2/4 identifies 7 cognitive biases that caused by "Not enough meaning". This is a really interesting blog post, and I recommend that you take a look at it.
  • Sometimes a headless browser might meet your needs helps you to understand that you should always use the right tool for the job. This means that sometimes writing automated tests that use a headless browser is a good choice, but sometimes you just need to test your features yourself.

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.

P.S. If you want to make sure that you don't ever miss Java Testing Weekly, you should subscribe my newsletter.

0 comments… add one

Leave a Reply