6 items found: Search results for "tdd" in all categories x
January 13, 2017 | Software Consultancy
The notorious FizzBuzz interview test was originally proposed as a way of weeding out candidates for programming jobs who – to put it bluntly – couldn’t program. The task is as follows:
Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.
It turns out that this problem has just enough subtlety about it to cause headaches to anyone who knows the basics but hasn’t learned how to think in nested structures.
November 3, 2015 | Software Consultancy
My JavaOne experience was rather busy this year, what with three talks presented in a single day! The first of these talks “Debugging Java Apps in Containers: No Heavy Welding Gear Required” was delivered with my regular co-presenter Steve Poole, from IBM, and we shared our combined experiences of working with Java and Docker over the past year.
November 21, 2014 | White Paper
In our latest white paper we cover the high level fundamentals of test automation, discuss the primary problems test automation solves and take a look at the steps required to implement this within your development process – all aimed at improving software delivery.
January 28, 2014 | Software Consultancy
A while ago I published this blog post about writing tests for mobile applications using Appium and cucumber-jvm.
In this post, I will look at an alternative approach to testing an Android native application using Cucumber-Android.
Throughout the post I will draw comparisons between Appium and Cucumber-Android, the goal being to determine the best approach for testing an android application using Cucumber. I will focus on the ease of configuration and use, speed of test runs and quality of reporting.
December 18, 2012 | Software Consultancy
The first thing most people think of when they start a project with the good intentions of test driven development is: write a test first. That’s great, and something I would fully encourage. However, diving in to writing tests without forethought, especially on large projects with a lot of developers can lead to new problems that TDD is not going to solve. With some upfront thinking (but not big upfront design!) a large team can avoid problems later down the line by considering some important and desirable traits of a large and rapidly changing test suite.