I’m loving NuGet and it’s totally changed the way I look at bringing in external dependencies to my projects. I’ve written about that before.

Sometimes, you need to install several packages into a project. For example, when installing SpecFlow, you might also need a test framework like NUnit or MsTest, and perhaps an assertion or mocking framework.

If you want a package that includes your or your company’s preferences, and is not necessarily suitable for publishing to NuGet.org, here’s how to create a local package with dependencies only.

Strategy

Our approach is to create a package that contains only dependencies—no code—and store it in a local NuGet Repository.

Install NuGet Package Explorer

Most of the work will be done in the .nuspec file, an XML file that you can edit with any text editor or use the excellent NuGet Package...

I recently started using a dark theme for Visual Studio. For those who haven’t checked out Studio Styles, it’s a fantastic site for finding great themes. I’m currently using the Son of Obsidian theme, but I also recommend checking out the Coding Instinct Theme created by my colleague Torkel.

However, I ran into an issue where the mouse pointer became almost invisible when editing text in the code editor with the dark theme. The pointer turned a dark gray, blending into the dark background, which was extremely frustrating.

After some digging, I found a solution in an old discussion. The fix involves changing the mouse pointer scheme in the Windows Control Panel. Here’s how you can do it:

1. Open Control Panel
2. Navigate to Appearance and Personalization
3. Go to Personalization

4. Click on Change Mouse Pointers

   This will open the Mouse Properties window:

   Read More

I recently received an insightful email from Jose Samonte asking for resources on Behavior-Driven Development (BDD) and where to start learning about it. Given the depth of my own journey with BDD, I thought I’d share my experiences and recommendations publicly.

Start Here

My introduction to BDD began with a blog post by Dan North: Introducing BDD. This post provides a solid foundation on the origins and principles of BDD. For further reading, Dan’s article “What’s in a Story” is also highly recommended as it delves into the concept of user stories in BDD.

Learn from Others

Much of the early work in BDD was done on platforms other than .NET, particularly in the Ruby and Java communities. Here are some key resources that have been instrumental in my understanding:

• The RSpec Book: This book offers an introduction to BDD within the...

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, Elijah Goldratt, and Gojko Adzic, among others.

Theory of Constraints

Last year, I read the insightful book, The Goal by Elijah 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 Steel-plates,...

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 ThenIDonTHaveThisStepDefinitionInPlaceYet() { ScenarioContext.Current.Pending(); } } 

However, ScenarioContext provides several other useful features:

ScenarioContext.Pending

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