Back in June 2014, at the annual Google IO in San Francisco, Google unveiled their newest, and much hyped cloud product, Cloud Dataflow. The demo they did that day, using a live twitter feed to analyze supporter sentiment during the 2014 world cup, got my mouth watering at the prospect of working with it. It looked downright freaking awesome, and I just couldn’t wait to get my hands on it to take it for a spin.
We recently introduced acceptance test driven development (ATDD) at a client. The idea was for the product owners, developers, and testers to work as a team to come up with the acceptance criteria for user stories before development begins. We adopted this approach as an attempt to increase a shared understanding of user stories, as well as a shared agreement on the definition of ‘done’.
As we introduced more functionality to the application, it became evident that more and more effort had to be put into regression testing prior to a software release. The application has to be supported on mobile (iOS and Android) and desktop (Safari, Chrome, Firefox, IE8 and above). Our team of 2 to 3 testers would spend up to 3 days testing for regressions! In an attempt to reduce the need for talented testers to carry out monkey work, the team began to push for a focus on automated browser-level testing.
In this post I will demonstrate the acceptance testing framework we used and describe how the test suite can be tied to a Jenkins build (with a beautiful results page!).
In this post I’ll talk about my experiences getting tests going, and how you can setup your own unit tests using PHPUnit and WebTestCase. I’ll start with my initial attempts to test directly against the DB, and the approach that I ultimately found most useful and practical.
I’ve also created an example Silex project that can be used to try out the various features of PHPUnit. The only prerequisite is PHP 5.4, which comes with most modern OS’s. You don’t even need Apache installed to try it out!
$(..) statements, maybe a
$('#message').hide() (or a
$('#message').slideUp(); if you were hip).
onclick="alert('...')", to be something that has grown up with us, and now appreciate. It is the only runtime language I can think of that will run on any modern processing device. It’s ubiquitous and the ecosystem has evolved beyond what anyone could have imagined, with many implementations (Rhino, V8, now Nashorn) and it’s very own matching server-side equal, node.js
Unit-testing Backbone Views is hard. You need to cover enough for the test to be meaningful (for example DOM updates and server calls), without getting too tangled up in gory details. In this post I’ll talk about how we use QUnit and Sinon.JS to unit-test our Backbone views.
There’s already material out there on using these frameworks together, so I’m not going to get into setting things up. However, having done it for a year now I feel I’ve learnt enough additional tips, tricks and traps to warrant sharing them with the world.
This post will cover the three things you have to think about when testing Backbone Views, then talk about three strategies for simplifying your tests. I’ll also share some more general thoughts on Backbone’s suitableness for building large apps.
Android’s built-in testing framework is lacking on a number of levels. Enter Robotium, an open-source project. Robotium connects the dots by extending Android’s testing framework and providing convenience methods to help developers rapidly create tests.
In this entry I will show how Robotium can be used for data input, finding and testing views and buttons, testing between multiple activities, and testing activities with extras. I’ll also show how to work around issues with race-conditions in UI tests. I have created a GitHub project with a sample application and test project.
This post is about unit testing with Groovy. Groovy was the first language I used after Java. It lets me do a lot of the things I do with Java, but more quickly. Like many developers who are using another language after Java for the first time – whether it be Ruby, Scala, Groovy or something else – I’ve quickly come to love it.
In this post I’m going to show you how Groovy can make your tests more succinct. We’ll focus on syntax sugar for creating and consuming Maps and Lists, which is something you do a lot of when preparing data for a unit test. Than I’ll give a quick introduction to closures, which will lead us into some of the techniques we can use for mocking in Groovy.
I’ve worked on a number of projects with Cucumber now, and I think it is a terrific tool. However, I’ve been seeing it used in ways that it was not originally intended for, the consequence being acceptance-test suites that grow increasingly slow, brittle and difficult to maintain.
These problems occur when developers start using Cucumber to drive overly-detailed tests. The problem of excessive UI testing with Cucumber has been blogged about in the past by Aslak Hellesøy – the creator of Cucumber – but I thought I’d cover some of my own experiences and opinions in this post.
The goal of this article is to discuss how improving the automated testing aspects of a continuous delivery project led to dramatic improvements in quality and delivered real business value to a leading bank in Melbourne Australia.
It will cover how the automated testing was integrated into the continuous delivery process to support Scrum, to empower testers and to shorten testing cycles.