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

But sometimes you want to install several packages into a project. For example, when you install SpecFlow into a project you also have to install a test framework such as NUnit or MsTest. And maybe an assertion framework or a mocking framework.

But this package will contain your (or your company) preferences and maybe not be suitable to publish to NuGet.org for everyone to download.

In this post I’ll show you how to easily create a  local package where you can setup the dependencies you want. And how to use it in your solution.

Strategy

Our sneaky plan is to basically create a package that only has dependencies. No code. And then store it in...

I have started to use dark theme for Visual Studio. You know about the site where you can get great themes, right? http://studiostyl.es/. I’m using the Son of Obsidian theme right now, but do check out Coding Instinct Theme by my colleague Torkel .

However – one thing that really bugs me was that the mouse pointer when in text edit mode (as it is in the code editor) goes to dark grey in the standard theme for Windows 7 (and XP and Vista, I understand).

That was a very complicated sentence but basically – my mouse pointer cannot be seen in the code editor. Very annoying.

I found the solution deep in a discussion here. “for cursor, select a windows black mouse scheme in control panel.”. That means the following – I didn’t even know you could do this:

• Open Control...

I got a very well formulated email from Jose Samonte the other day. He asked me about some resources on BDD and where to start learning about it. As I think this is a great question and I’ve struggled and read a lot before I got a grip on BDD I thought I post my answer publicly.

Start here

It all started with a blog post by Dan North; Introducing BDD. It provides some context on where the ideas came from and is a good read. While you’re there you should read “What’s in a story” – that article is equally good and provides a great background and understanding.

Learn from others

Now that we know the background and history we should go on. Much of the early work (and current to be honest) of the BDD was done on...

A lot of people read and appreciated the last post on Specification by example and Theory of constraints, so I thought I do a follow up.

I often find that your closest people are your best critics, so I asked a few of my colleagues for feedback. Håkan Forss (@hakanforss) is one of them that I respect very much in matters like these. He, like me, read and loved the Goal and I know that Håkan has great knowledge about theory of constraints and applying that kind of thinking in the system development process or other kind of knowledge work.

So it came as no surprise that Håkan had a few, rightful, objections to my reasoning. He’s points made me think another lap and I thought that it could be interesting to present it here.

To be able...

Since the first time I heard about Specification by example (or BDD if you like) I have had this nagging feeling that it fits like a glove with Lean thinking and the theories surrounding those ideas, but I haven’t been able to figure out how or why. Today I had some time to think hard about that and I think I found a connection. The connection I saw was how theory of constraints can be applied with the use of Specification by example to the system development process itself. In this blog post I’ll try to explain what I mean by that.

Standing on the shoulders of giants

This blog post is merely formulating my thoughts on this, or laying the puzzle from a lot of different pieces that other people have supplied. There are even people who supplied the complete picture, so...

If you are a developer doing BDD, as me, you’ll soon run into the joys of UI automation. The BDD community to day 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 is 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...