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

  • A Guide to JMockIt Expectations describes how you can stub methods, specify expectations, and verify interactions with JMockIt. This post is written by using the cookbook format, and you can use it as a reference manual.
  • JUnit 5 - An Early Test Drive - Part 1 provides a very comprehensive introduction to JUnit 5. For example, this post identifies the reasons why people felt that they need to rewrite JUnit, describes the architecture and modules of JUnit 5, and explains how you can write automated tests with JUnit 5.
  • Using JUnit Rules to simplify your tests introduces three basic JUnit 4 rules that help you to simplify your unit tests. Also, it describes how you can achieve the same goal by implementing custom JUnit 4 rules.

The Really Valuable Stuff

  • An approach to test your user interface more efficiently describes the difference of testing the user interface and testing application logic through the user interface. It also explains what the Model-View-ViewModel (MVVM) pattern is and provides a quick introduction to testing user interfaces that are built by using the MVVM pattern.
  • Found an awesome tool to create wonderful screen captures identifies the tool that the author uses for creating animated GIF images. So, what has this got to do with testing? Quite a bit actually. When you find a bug, you can create an animated GIF that shows how you can reproduce the bug AND attach that GIF to the bug report. This is a powerful technique that helps developers to see how a particular bug can be reproduced. The thing is that bug reports are quite often imperfect and often I have to send the report back to original reporter because I couldn't reproduce the bug by following the instructions given on the bug report. Often the reason is that I misunderstood the instructions. This tool ensures that you cannot misunderstand the instructions because you can see how you can reproduce the bug. In other words, this tool helps you to save time, your nerves, and money.
  • Setup Assertions is a really short blog post but the author makes an excellent point. If you don't follow his advice, you will end up with a test suite that is not as easy to read as it could be because your assertions shift the readers attention from the setup code to the assertions. In other words, these assertions help you to hide the essence of your test case, and this is not (surprisingly) a good thing.
  • Unit Tests Anti-patterns: TDD without refactoring demonstrates how you can remove copy-paste code from your test suite by refactoring your tests. Even though the example described on this post is quite simple, I think that it is still valuable, especially if you have just started writing automated tests. I think it is fine to use copy-paste when you write your tests, but you should refactor your tests as soon as you notice a chunk of copy-paste code that can be removed.
  • Whose fault is it anyway? is a post that describes when can happen if you concentrate on finding someone to blame when things go wrong. The moral of this story is: don't play the blame game. Concentrate on improving your communication skills, and remember that no one is perfect. Everybody make mistakes (this includes you) and the best way to deal with the situation is to just fix the problem ensure that it doesn't happen again in the future.

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