background preloader

Introducing BDD «

Introducing BDD «
History: This article first appeared in Better Software magazine in March 2006. It has been translated into Japanese by Yukei Wachi, Korean by HongJoo Lee, Italian by Arialdo Martini and French by Philippe Poumaroux and most recently into Spanish by Oscar Zárate, Turkish by Selim Öber and Russian. I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails. The deeper I got into TDD, the more I felt that my own journey had been less of a wax-on, wax-off process of gradual mastery than a series of blind alleys. My response is behaviour-driven development (BDD). Test method names should be sentences My first “Aha!” renders something like this: I had introduced a bug. and one for the event:

Related:  AgileTest Driven DevelopmentTesting

Mocks Aren't Stubs The term 'Mock Objects' has become a popular one to describe special case objects that mimic real objects for testing. Most language environments now have frameworks that make it easy to create mock objects. What's often not realized, however, is that mock objects are but one form of special case test object, one that enables a different style of testing. BDD vs TDD: A Behavior-Driven Development Example Testing. It often gets left to the last minute, then cut because you’re out of time, over-budget, or whatever else. Management wonders why developers can’t just “get it right the first time”, and developers (especially on large systems) can be taken off-guard when different stakeholders describe different parts of the system, like the story of the blind men describing an elephant. It’s inevitable, however, that the first step in every project is a discussion about the behaviors of the software or feature to be built.

What’s in a Story? [This article has been translated into Korean by HongJoo Lee, French by Philippe Poumaroux, Spanish by Adrian Moya, Russian by Denis Oleynik, and German by Julia Kadauke.] Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. TDD : Introduction to Moq In this post, I provide an introduction to Moq which is the newest of the Mock Object Frameworks. Moq is promoted by its creators as easier to learn and use than other Mock Object Frameworks such as Rhino Mocks and TypeMock Isolator. Moq takes advantage of recent VB.NET and C# language features such as lambdas and generics.

Behavior Driven Development — behave 1.2.5 documentation Behavior-driven development (or BDD) is an agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. It was originally named in 2003 by Dan North as a response to test-driven development (TDD), including acceptance test or customer test driven development practices as found in extreme programming. It has evolved over the last few years.

JUnit Testing Spring Service and DAO (with In-Memory Database) This post describes how to implement JUnit tests for a Spring Web Application’s Services and DAO. It is built on top of the Spring MVC-Service-DAO-Persistence Architecture Example. This example is available from Github in the Spring-Web-JPA-Testing directory. Reminder Test Fixture – The fixed state used as a baseline for running tests.Unit test – These tests verify that pieces of code (components) perform some functionalities as expected. Adapting to Inversion of Control and Dependency Injection You might have come across the phrases IoC, Dependency Injection, Mocking among others, these are commonly used when talking about “Inversion Of Control” which is the full meaning of the abbreviation IoC. So what is this “IoC” that everyone is talking about? Inversion of control is a principle in Software Engineering, let’s just take a look at the Wikipedia definition of this In practice, Inversion of Control is a style of software construction where reusable generic code controls the execution of problem-specific code. It carries the strong connotation that the reusable code and the problem-specific code are developed independently, which often results in a single integrated application. Rather than explaining the text below, let me show an example of an application that does not follow this principle, but will when we’re done here!

BDD – TDD done well? Someone on the XP thread suggested, “BDD is just TDD done well with different words.” Here’s my take. An application is the end-product, and the value of the application is delivered through its behaviour, as perceived through its user interface. BDD uses descriptions of behaviour and executable examples (or exemplars; examples carefully chosen to illustrate a particular behaviour). These exemplars, whether in code or plain English, are an aid to communication, to driving a clean, simple design, to understanding the domain, to focusing on and delivering the business value, and to giving everyone involved clarity and confidence that the value is being delivered.

John Ewart » DAO Testing with Hibernate I’m currently building some web services using Dropwizard (Jetty, Jersey, Jackson, Hibernate all bundled up), and needed to test the DAO. Dropwizard has some convenient interfaces to load configuriation files and bring up hibernate sessions, etc. when the service boots up; however, this does not translate well to JUnit tests (there’s a lot of plumbing involved in making a Service that doesn’t translate to tests.) Fortunately, though, since it’s all just sugar coating you can just as easily setup your own sessions and transactions. I found that creating a parent class for my DAO tests that does all the setup is a convenient way of handling all the plumbing you need.

Getting started with a Mocking Framework In previous articles we’ve looked at how to increase code quality by either introducing test drive development for new features or using inversion of control. There are of course many other aspects that come into play when you want to reach high-quality code and this article is going to introduce you to mocking that will help you along the way. You might have come across the word “mock” before, when for instance a UI designer for a Windows Phone application on your team puts together a picture of how the application might look when it is finished: Where do the buttons go? What text might be displayed when the button is pressed? The word “mock” means to fake something, which is exactly what we want to do here; we want to fake the layout to give the customer an idea of how the application will look or how it will behave.

BDD by example tl;dr: Send us your examples of real world BDD. Read on to find out why. The panel Learn Spring MVC 3, Hibernate, Maven, and TDD When it comes to unit testing data access components, some people would be able to debate the exact definition or a unit test. Some say that a unit test that involves database related code must communicate with the database in order to be a true unit test. Others say that a unit test that communicates with the database is an integration test, not a unit test. What do you think? Well, here is what Michael Feathers thinks, as quoted in his book “Working Effectively With Legacy Code” (Addison-Wesley, 2005)

Scrum Process for Software Development using Microsoft Visual Studio Scrum 1.0 Process Template Picture 1: Pictorial representation of Waterfall, Iterative and Scrum Software Development methodologies. The waterfall approach is highly risky, often more costly and generally less efficient than more Agile approaches. It requires the creation of up-front documentation before any real business value is created. i.e.