Oct 032014

James O. Coplien started a discussion in May 2014 about the value of UnitTests and why most of them are waste. In August he added the 2nd installment.

In this context I hear often the argument that the majority of tests should be UnitTests over all others. Mike Cohn suggests this as well with the layout of his Testing Pyramid, because UnitTests can be executed faster. Robert C. Martin (Uncle Bob) is a strong advocate of this too – see one of his recent blog entries. Later on I will come back to his blog post and his statement that a UnitTest framework must not slow down the developers’ pace. But first to the “argument” that UnitTests can be executed faster than the others:

When I talk in the following text only about End-To-End (E2E) tests, then as a pars pro toto for all kind of tests that check not just a single unit, but complex business logic or complete features.

So shall we write UnitTests “only” because they are executed faster than E2E tests? This sounds to me like some kind of a workaround. Because we cannot get easily execute broader applied tests fast, we test something that we can test faster? Exaggeratory, isn’t it somehow similar to the old joke below?


Continue reading »

Dec 202011

The deepest impact on my side was studying the following books during the last year: Continuous Integration by Paul M. Duvall, Steve Matyas and Andrew Glover and Continuous Delivery by Jez Humble and David Farley. These books and presentations during the OOP 2011 in Munique pushed me into the direction that I am trying to describe below.

Before I go into details how we use Cucumber, I want to describe a little bit our environment: In our company we are developing a medical application that can run as a standalone application or in a client / server setup. Each configuration consists for the user of three UI processes and about fifteen background processes or services. The data persistence is realized with a PostgreSQL database, which is handled through one of the service processes. It is a radiological reviewing workstation that is highly optimized on high volume throughput. The image data for each patient can easily be about 2.5 GB and the technical challenge is to display any of next possible radiological images, which can have easily 26-50MB each in less than a second, because our customers are used to diagnose about 60-120 cases per hour. Depending of the current workflow step, the user has to work with a different UI process.

The application has about 2,000,000 lines of C++ code, currently about 10.000 single requirements and most of the functional tests are manual paper based or steered by our test management system SpiraTest. So it is obvious that we have plenty of work to do. Beside the fact that we have way too much requirements or be more precise that the granularity of the requirements is too fine, certain parts of the code are hardly testable in an automated way. Our transition from the V-model to SCRUM two years ago brought up dramatically the fact that test automation is one important step for us to stay productive and ensure quality.

Continue reading »

How we Came to Hudson/Jenkins CI as Continuous Build System

 Development Process  Comments Off on How we Came to Hudson/Jenkins CI as Continuous Build System
Mar 082011

During our phase to installing the SCRUM develop I read the book “Scrum – Agiles Projektmanagement erfolgreich einsetzen by Roman Picher” and there was recommended to use a Continuous Integration (CI) system. The reasons stated there persuaded me at once that we need such a system. So I started to looking for such a thing.

The very first system I set up was CruiseControl, because an other department in the company already used CruiseControl .Net. The setup of the server was pretty easy. But I did not like the way of configuring the jobs. Too many settings had to be done in an “XML grave”.

So I took a look onto the commercial Cruise by Thoughtworks. The setup was easy and support by the help desk was great during our evaluation phase. But still it was necessary to configure the job details with XML files. It may be that this has changed with a later revision.

I think XML is a good way of defining settings or transferring data – for machines. But I don’t think for humans.

I liked very much the pipeline concept that Cruise has implemented! But I did not had at that a budget of about 7000€ for buying such a license. So I found a great comparison list.

Only one system which offered all features that I would like to have: Hudson CI. The installation was as easy as it was for all the other systems. But there was no need to configure anything within an XML file. Everything could be set via a web interface. Great! Everything was translated to German. Wow. (Even I prefer today the English layout, because this eases the possibility to search for solutions of problems in the net.)

Continue reading »