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

  • Automate Amazon: Writing a Shopping Cart Test is the latest part of T.J. Maher's Automate Amazon tutorial. It explains how you can write a test which ensures that preserves the prize of a product that is added into a shopping cart. This means that the prize shown on the review shopping cart page must be the same as the prize shown on the product page. By the way, this post assumes that you have read the earlier parts of this tutorial.
  • JPA test case templates introduces test case templates that can be used for providing a failing test case when you report a bug found from the Hibernate ORM. This is an excellent idea because writing a test case takes time and this means that some people might not want to do it. These templates eliminate this excuse because they do all the heavy lifting. In fact, I think that all open source projects should provide similar templates.
  • Robot Framework Tutorial 2016 – Keywords provides a quick introduction to keywords. This well-written blog post describes how you can use the existing keywords and write your own keywords which are based on the existing ones. If you are looking for a good Robot Framework tutorial, you just found it.
  • Testing persistence with Arquillian on TomEE describes how you can write integration tests for Java Persistence API by using Arquillian and Apache TomEE. Some of you might know that I am a Spring guy, but that doesn't mean that I cannot appreciate a useful testing framework just because it uses Java EE. I have to admit that I am quite impressed with Arquillian. The tests described in this blog post look very clean, and it was nice to see that things have improved a lot during the last five years.
  • Testing With Spock: The Logical Choice is a recording of the SpringOne 2GX talk that was given in Washington DC by Iván López. It describes the basic concepts of Spock Framework and demonstrates how you can write clean tests with less code. This talk is about 85 minutes long, but if you want get a quick introduction to Spock Framework, you should take a look at this video.

The Really Valuable Stuff

  • Assisting with inquiries: Introduction is the first part of a series that helps to share the information you find during testing. The thing is that testing doesn't reveal just bugs. You will most likely find incomplete requirements that must discussed with the stakeholders of your software project. If you want to have meaningful discussions with these people, you need to provide relevant and useful information to them. This is obvious, but too many people fail to do it. That is why this series is extremely useful (assuming that the rest of posts are as good as the first one).
  • Mapping biases to testing, Part 1: Introduction is the first part of a series where the author describes her learning process as she tries to get rid of thinking biases that are described in the book titled: Thinking, Fast and Slow by Daniel Kahneman (it's an excellent book btw). This post describes the basics of fast and slow thinking and identifies the things that are discussed in the next parts of this series. If you like Daniel Kahneman's book, you will like this series as well.
  • Mobile Testing Cheat Sheet identifies 32 different section that you must take into account when you are developing and testing mobile applications. If you are writing web applications, you probably never think about things like battery usage, mobile networks, or sensors. However, these things are essential if you are writing (or testing) mobile applications. Anyway, I recommend that you take a look at this cheat sheet. I am sure that you will notice something that you should probably test (even if you are writing web applications).
  • Outdated testing concepts #1 busts the myth which states that testing is so easy that anyone can do it. This myth is alive because people think that testers are basically just bug finders who execute a predefined test plan. I think that testers are more like information providers who seek information developers and other stakeholders might have missed. They might find bugs, but they might as well find a usability problem or a missing requirement. That doesn't sound like a job that can be done by mindless zombies.
  • Re-Inventing Testing: What is Integration Testing? (Part 1) is a discussion between a mentor (the author) and a student. They started their discussion when the author asked this question: What do you mean by integration testing? When I read that blog post, I realized that even though these two people are talking about integration testing, the lesson of this post (IMO) is that we should define a term before we use it because it is the only way to avoid misunderstandings.
  • Test Automation Helpful Tips provides a very good description of the test automation pyramid and describes why it is not a good idea to write too many tests that belong to the upper levels of that pyramid. However, the most interesting part of this blog post talks about the collaboration between developers and testers, and explains the difference of testing and checking.
  • Testing: Appetite Comes With Eating explains why the author started writing automated tests for his code. It's a quite common story. I think that the company/team culture has a huge effect on the way we work. If you want to be part of the solution, you have to encourage your colleagues to write tests and help anyone who is interested.
  • Thoughts: Should I stay or should I go now? is an inspiring blog post that identifies the reasons why the author decided to leave her testing jobs. In the end of that blog post she also explains why she hasn't left testing. The reason why this post inspires me is that you could replace the word tester with the word developer and it would still make a lot of sense.

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.

1 comment… add one

Leave a Reply