The Pragmatic Tester

I attended the 2017 WeTest Conference in Wellington, NZ on Monday 18 September. Wellington has a great test community and conference itself had a friendly vibe and lots of interesting talks. The most interesting talk was “Machine Learning for Testers” by Kathryn Hempstalk. She described what Machine Learning is (in simple terms it is an algorithm plus data that produces a model) and gave us some examples along with the caveat that it will not solve all business problems. She recommends testing from the start of the process. The most practical talk was by Daniel Mcclelland on debugging proxies. While I’ve used debugging proxies such as Fiddler and Charles before, Daniel gave us some tips on using breakpoints to simulate network failures that I’ve already put into practice. The most inspiring talk was Angie Jones’s closing keynote “Owning Our Narrative“. She took us on a journey through contemporary music history and made an analogy between a musician and a tester and

In my previous two blog posts I talked a lot about unit tests and how to write valuable unit tests. But what about integration tests? When should you write these, and how do you write valuable integration tests? I’ll try and answer these questions in this blog post. Integration Testing Integration tests operate on a higher level of abstraction than unit tests. The main difference between integration and unit testing is that integration tests actually affect external dependencies. Integration tests interact with external dependencies and are therefore much slower than unit tests. Integration tests are needed to test the application services layer, which interacts with external systems. You may have direct control over some of these external systems, such as a local database, or they may be third party systems over which you have no direct control. In my previous blog post I discussed the Collaboration Verification style of unit testing and how it is not a good style for unit te