18 May 2017

Rediscovering TDD - My favourite flavour of TDD

software-craftsmanship tdd test-driven-development java java8 spock groovy

As promised in the previous post, it's time to show how I do TDD. It is an advanced TDD blog post in a sense that in order to appreciate it fully, one should have probably tried various approaches, be aware of some shortcomings when picking either classic or mockist approach etc. At the same time, this blog should be understood even by beginners as this is yet another way of doing TDD. Nothing prevents a person that has never tried TDD to apply this particular approach, even if they do not know the difference between above mentioned classical and mockist TDD. In fact, I think that the industry as a whole would be much better off if the first style of TDD that newcomers come across was the one presented here.

Read more
31 January 2017

Rediscovering TDD - Preface

software-craftsmanship tdd test-driven-development

Almost every software developer at some point comes across Test Driven Development. As far as I remember I was lucky enough to try it just after I started my professional career. I remember my first interview and my first day at work. I remember how surprised and happy I was that some company trusted me enough to allow me to change their codebase - and to be rewarded for it. Thus, soon after I joined, I spent almost all my free time learning about the framework I used and about all these practices every developer should do. Proper testing, better even, Test Driven Development, was one of them.

Read more
11 June 2016

Testing Business Rules - part 3

concordion behavior-driven-development specification-by-example

In the previous post I created and instrumented the specification that will guide us while implementing the feature. In this post I am going to explain how it is possible that one can run such specification and check if the functionality works as expected.

Read more
6 June 2016

Testing Business Rules - part 2

concordion behavior-driven-development specification-by-example

Every time some part of the world that we care about (i.e. the domain around which we build the system) becomes well-defined, it is not a bad idea to write our findings down. By creating a clear rules describing business, our small world has been divided into two areas: one that complies with the newly discovered business rule and one that violates it. In order to make sure the cut is precise and the system evolves without breaking that constrains, you need a tool: a business rule test. This article shows how to run business tests efficiently.

Read more
25 August 2014

Testing Business Rules

behavior-driven-development specification-by-example

In the previous article I presented one group of the business-facing tests I often use, which is Automated test case / use case. These tests help people understand the flow, the process and the actor’s interaction with the System Under Test. However, if you want to build a non-trivial system and you aren’t the only stakeholder, this is not enough. In order to deeply understand and validate our assumptions we need more fine grained tests. Today I’ll show you how to create such tests and be almost sure that you and other stakeholders are on the same page.

Read more
7 June 2014

Automated test cases

behavior-driven-development testing

There are many types of tests. We need more than one type, because we focus on different characteristics of the system. The human readable tests (e.g. created using Gherkin language) are not an exception to the rule.

In the previous article I presented the test scenario that was far from ideal – mainly because we were focused on too many aspects at once. My intention was to refine that scenario in the upcomming articles by splitting it into many scenarios of different types in order to make it easy to comprehend, maintain and run. In this article I’m going to describe one of the types I use – an automated test case.

Read more
4 February 2014

Make it readable

behavior-driven-development specification-by-example

Imagine that your department is building a web application for some banking institution and the purpose of this app is to help the bank customers understand better what happens with their money when they perform operations like opening a deposit account, making a consolidation loan etc.

In order to share common understanding of what exactly should be built, you decided to use Specification by Example. You’ve heard that one of the ways of doing this is to create scenarios describing required features. You’ve also heard that these scenarios should be runnable like any normal test and should automatically verify if the app behaves as expected. After several discussions with stakeholders, many of which were subject-matter experts, you prepared wireframes that should help you communicate with them better. Most of the people are visualizers after all and these wireframes help everyone express their vision and decide what they really want. You used these wireframes during the requirements gathering session.

Read more
23 December 2013

Specification by Example

behavior-driven-development specification-by-example

A few weeks ago I attended the local JUG meeting, topic of which was Specification by Example and Living Documentation. When the speaker asked if anyone had used this technique in their work, three people (from round about 30 attending) raised their hand. “10%, could be worse” he surely thought. The point was, we were all from the same company and we’d been using it because I convinced developers and management of my company to employ it. So, excluding us, no one had used it before. Why is that? People don’t need it, don’t get it or maybe haven’t heard of it?

Read more