Java Testing Weekly 18 / 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

  • Accurest and Stub Runner 1.1.0.M3 introduces the new features of the upcoming Accurest 1.1.0 release. Accurest is a testing library that allows you to stub HTTP calls and messaging functionality. The funny thing is that even though it looks very useful, I heard about it only a few weeks ago. That is why I decided to help spread the word.
  • Achieving 100% code coverage. Testing getters and setters. is a post which proves that you get what you measure. In an ideal world no one would require you to have 100% code coverage because it is "impossible". However, the sad truth is that you might face this requirement. If you do, this blog post will get you off the hook.
  • Data driven JavaScript tests using Jasmine identifies a fundamental shortcoming of Jasmine (it doesn't support data-driven testing) and provides two workarounds that help you to write data-driven tests with Jasmine.
  • Introduction to JUnit 4 is a collection of three free lessons of my Test With Spring course. These lessons provide an introduction to JUnit 4 test classes, test runners, and rules. Note that these lessons are meant for people who haven't used JUnit 4.
  • Introduction to PowerMock describes how you can overcome the limitations of Mockito by using the PowerMockito Mockito extension and PowerMock. Although I think that you should never use PowerMock in a greenfield project, I agree that can be useful if you are working in a legacy project that has a messy code base which was not designed to be tested.
  • Unit tests with custom JUnit rules, annotations and resources describes how you can create a JUnit 4 rule that reads the test data, which is given in JSON, from a file and transforms it into an object. The tests of the original examples only write assertions for the created objects, but I think that you can use this technique for creating tests that read their input data from a JSON file and pass it forward to the tested method.

The Really Valuable Stuff

  • If and when you should use Test-Driven Development is a pretty comprehensive post that describes both the pros and cons of test-driven development. It also identifies the reasons why TDD is not used more often in real life. This post raised many thoughts and I like the fact that the author suggested that developers value short term gain more than the long term gain. Sadly, I have noticed that same thing, but I don't think that it is the biggest reason why developers won't do TDD. I think that developers don't use TDD because it is a lot harder than writing the tests after the code is written.
  • It’s All A/Bout Testing: The Netflix Experimentation Platform describes how Netflix does A/B testing. I know that some people probably think that A/B testing doesn't belong to this "newsletter". However, I think that we should study every technique that helps us to build better products, and no one cannot deny the usefulness of A/B testing. Also, since this blog post is quite interesting, I decided to add it here.
  • Test Automation – Am I the only one? is a post that might look like a rant, but actually it is a post that provides a good description of the challenges (or problems) of test automation. If you have extra time, I recommend that you read the comments as well because they might be even more useful than the blog post.
  • The abysmal state of ‘testing’ in 2016 is a rant which argues that automated testing isn't the same thing as testing that is done by humans. I enjoyed reading this rant (I enjoy good rants), but I think that is a bit concerning that so many people seem to think that test automation removes the need of testing. This is absurd. Everyone, who has tried to automate a complex workflow, should know that it cannot be done because it's too expensive and the created tests are often so brittle that everyone just ignores them.
  • What problems do we have with our test automation? identifies four concrete problems that the author's team has faced when they have been automating their testing efforts. I love the fact that this post is based on real experiences and it also provides some tips that might help you to avoid or solve these problems.

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