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

  • JUnit 5 – Architecture describes the architecture of JUnit 5. It seems that this new JUnit version is totally different than the old one (at least from the architectural point of view). I think it is a good thing because JUnit 4 has a few very irritatations limitations that are (luckily) fixed in JUnit 5. Anyway, if you want to get a good overview of JUnit 5 architecture, I recommend that you read this blog post.
  • Introduction to Selenium WebDriver explains why you should use Selenium WebDriver instead of Selenium RC, provides a quick overview of the Selenium WebDriver architecture, and takes a quick at its API. I think that this post is a good read for a person who has no experience of Selenium WebDriver and who wants to get a quick overview of its architecture and API.
  • Multiple libraries for assertions in your test classpath describes the problems you face if you have multiple libraries that are used for same purpose in your test classpath and explains how you can solve these problems by using only one library for one purpose. For example, you are allowed to use only one library for writing assertions. I agree with the author, but there are situations when you need multiple assertion libraries. For example, if you are using Spring MVC Test, you need to use Hamcrest in your controller tests. If you don't want to use Hamcrest in other tests (I don't), you need to have two assertion libraries in your test classpath. That being said, I think that it's a good idea to minimize the amount of libraries that are used for same purpose.
  • Running your tests in a specific order describes how you can run your automated tests in a specific order by using JUnit, TestNG, and NUnit. More importantly, this blog post describes why you have to do this in some cases even though this is considered to be an anti-pattern. The truth is that sometimes you have to choose the lesser of two evils. If you are in a situation where you must run your test in a specific order, this blog post will help you to achieve your goal.
  • Testing Angular 2 Applications helps you to write both unit and integration tests for a simple web application that uses Angular 2. This blog post uses Jasmine for unit testing and Protractor for integration testing. If you want to get started with Angular 2 and automated testing, this tutorial is a good place to start.
  • Why Test Engineers Should Learn Geb and Spock explains why you should learn to write automated tests with Geb and Spock, and helps you to get started with these tools. I think that this an is extremely useful blog post because I have noticed that Spock Framework helps me to write tests that are easy to read and write. If you are ready to see how deep the rabbit hole goes, you should definitely read this blog post.

The Really Valuable Stuff

  • How to Make Your Test Automation Efforts Visible to Everyone on the Team provides a lot of useful tip that help you to make your test automation efforts visible to your team members. I think that these tips are helpful because writing automated tests take a lot of time. I have noticed that some developers don't write tests because they are afraid that if they do write tests, they don't look as productive as their team members (who might not write tests). If are feeling this way and you want to find a way to start writing tests, you should take a look at this blog post.
  • When should you Stop Testing? provides useful tips that help you to decide how much manual testing you need to do. The thing is that the tips given by this post are also useful for developers who are writing automated tests. The truth is that you don't have enough time to write the tests that test all possible scenarios. Thus, you have to choose which tests you will write. This blog post helps you to do it.
  • Why I still like pyramids explains the history of the test automation pyramid, identifies its problems, and describes why the pyramid shape is still useful for demonstrating testing efforts. It's quite easy to understand why "manual" testers do not like the test automation pyramid. The reason for this is simple: some version of the pyramid suggest that manual testing is basically worthless. If you are a manual tester, you are naturally pissed off because these versions of the test automation pyramid suggest that you are worthless. That is why I think that we should have different pyramids for automated and manual testing. There is no need to put these two things to the same pyramid because we cannot apples and oranges. Anyway, if you want to get more information about this, you should read this blog post.
  • Writing Tests Doesn’t Have to Be Extra Work is an excellent blog post that explains why automated testing isn't extra work even if you might feel that it is. I know that am walking on thin ice, but I still have to say this: if you know that automated testing is something that you should do, why on earth are you not doing it? Figure out an answer to that question and solve the problem that prevents you from writing automated tests.

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