Following up on my previous post about Specification by Example and Theory of Constraints, I’ve received insightful feedback from colleagues, particularly Håkan Forss, whom I greatly respect.

The Five Focusing Steps

Håkan pointed out some valuable perspectives on the Theory of Constraints’ five focusing steps:

1. Identify the Constraint
2. Decide How to Exploit the Constraint
3. Subordinate All Other Processes to the Above Decision
4. Elevate the Constraint
5. If the Constraint Moves, Return to Step 1

Assuming the Goal of the Organization

The first step is to articulate the goal. In system development, this might be phrased as:

Develop a system that meets the needs of the users

Understanding the goal of your project can help direct the focus of improvement efforts and influence how trade-offs are managed throughout the process.

Identify the Constraint

In physical systems, identifying constraints is often straightforward—like observing...

Since I first encountered Specification by Example (or BDD as it’s also known), I felt it had a natural alignment with Lean thinking and related theories. Today, I want to explore how the Theory of Constraints can be applied through Specification by Example to enhance the system development process.

Standing on the Shoulders of Giants

This post reflects my own thoughts and tries to piece together insights from various experts. I owe much to pioneers like Dan North, Eliyahu Goldratt, and Gojko Adzic, among others.

Theory of Constraints

Last year, I read the insightful book, The Goal by Eliyahu Goldratt. Goldratt’s Theory of Constraints (TOC) asserts that every system has at least one bottleneck that limits its overall performance. Improvements to other areas are less effective if they don’t address the bottleneck.

Here’s a simple example:

Imagine Marcusoft Welded Steelplates,...

If you are a developer doing BDD, as me, you’ll soon run into the joys of UI automation. The BDD community today seems to lean towards running your specifications/test end-to-end in order to capture the whole stack of the application as well as getting great regression tests.

But tests against the GUI can be brittle, that part of the application is the one that most often is changed, in my experience. So writing automated stuff (in essence programs) against a changing environment is not very pleasant as you might well know.

This post is about using the Page Object pattern that can help you handle this brittleness as well as structuring your test code in a nice, maintainable way. That in turn will help us to place code in the right place – which I like. Some guidelines, if you like.

Inspiration

I have of course not invented...

Recently, I had the chance to explore more advanced error handling with SpecFlow and delved into the ScenarioContext and FeatureContext objects. These components offer some powerful capabilities that are worth understanding. In this post, I’ll take a closer look at both and offer some tips on how to utilize them effectively in your SpecFlow projects.

ScenarioContext

Most of us have encountered the ScenarioContext in the code generated by SpecFlow when a step definition is missing:

[Binding] public class StepDefinitions { [Then(@"I don't have this step definition in place yet")] public void ThenIDonTHaveThisStepDefintionInPlaceYet() { ScenarioContext.Current.Pending(); } } 

However, ScenarioContext provides several other useful features:

ScenarioContext.Pending

The Pending method is well-known for marking steps as pending when...

It’s been a while since I did any work on the KanbanBoards project, but now I got around to add some more features. I planning on doing some acceptance tests for creating new boards. The controller functionality was spec’d out in then last installment of the series.

To do that properly I need to touch on two main areas of functionality:

• Authentication – here I plan to use OpenID and see if I can plug-in some functionality that already exists.
• Uploading pictures – just for fun I will try to store the pictures in the database and see how that sits. I can already here give away the fact that I didn’t do this today.

And finally show that the whole thing works using an acceptance test that verifies the functionality end-to-end.

Let’s go.

Feedback and updates

I got some great feedback from some people,...

I have been talking about BDD or specification by example almost every day for a year and a half now. I still love the idea—executable specifications that everyone concerned can read, so you can talk about the behavior of the system before a single line of code is written. Yeah, you see, as soon as I start to write about it, it’s hard to stop.

Most people (or roles rather) react positively to this idea; developers love the possibility to get a detailed specification to start from, testers see great promises in automating the tests, and requirements people love the traceability features and the level of detail that you get before you start.

It’s the workflow or process that is the “problem.” How do we organize the work around this? Who writes those features? Where are they updated? I have blogged about this several times before, but...

I got an invitation to the Sweden Progressive .NET (the group formerly known as Alt.Net Sweden) to do a presentation on SpecFlow. I know many of the people in this group, a lot of them work for Avega, and have the highest respect for their knowledge.

So to get an invite from them to talk about a BDD tool was really cool, and a bit nerve-wracking. But it also made me step up my game and I put quite a lot of time into creating a demonstration project that shows the different features of SpecFlow and how to use them effectively.

Of course, I created features for them so that you can easily read and understand them without even having to look at code. This was inspired by how TechTalk themselves spec out new features of SpecFlow and proved to work very well. I plan to update them as new...