I’ve been asked to train a group of developers in the use of SpecFlow so that they can use it to write Selenium Tests. So, in an attempt to “kill two birds with one stone” I thought today’s post would cover how to get the SpecFlow environment setup. Not only will it help me prepare for the training session I will be leading, but it will help me when I need to set this up the next time because it tends to be a bit confusing when you setup a new project. You’ll see why in a bit.
For the purposes of this post, I’m going to assume that you already have the NUnit Test Runner installed. The question you are looking to get answered is, “How do I run NUnit from Visual Studio” or even more importantly, “How do I DEBUG NUnit test from Visual Studio”. The following step by step should help you.
Right click on the project in Solution Explorer that represents your test project. From the resulting menu, select “Properties.” In the resulting window, selec the “Debug” tab from the left-hand side of the window. Continue reading “Run NUnit from Visual Studio”
As you start your journey down the road of Unit Testing you will discover that part of what makes code testable is this concept of Dependency Injection. As you explore further, you will see people mentioning various Dependency Injection frameworks. You may naturally assume that to implement Dependency Injection, you will need to select an use a Dependency Injection framework.
But, Dependency Injection has nothing to do with using a Dependency Injection framework. The frameworks are there because:
1. much of our existing code is code that has too many dependencies and the framework helps us break those dependencies without having to refactor too much of our code and
2. to give us a way to easily swap out one object for another when our code is structured in such a way as to not have dependencies at all.
Last week we looked at a few excuses developers give for not testing their code as they develop it (Excuses For Not Testing). We finished that by mentioning that most of the code you write simply isn’t testable. You can’t practice Test Driven Development on something that isn’t testable in the first place.
And there, folks, is why Johnny can’t test.
As I started my own journey into unit testing, I slowly began to realize that it was really easy to come up with reasons to NOT test my code as I was writing it, even once I understood what that was supposed to look like. The reason I think most programmers don’t unit test code, once they understand what it is they are supposed to be doing is that they don’t feel like they have permission.
To this I also answer, “How much permission do you need?”