I have been developing lately using Behavior Driven Development, or BDD. I am not using a "true" BDD "product" like Behave# at the moment, so I am merely attempting to tailor my tests to focus on behavior. Thus far, I have focused more on business objects, so the tests are a bit less use case type of behavior, but I like what I see thus far.
I am not using VS 2010, which allows you to use a test first approach. This is not a major issue, overall, except that I am not being a true purist at the moment. I am stubbing in the classes prior to the test, in many cases. When I do, I stub in so the tests red light. I wish 2010 was already out, so I could be a better boy, but I am not going to install 2010 on a machine where i am doing productoin work. That is fine, as you cannot install it now anyway. 🙂
DISCLAIMER: I am new to this.
Her eis how I see it with business objects. I will read some more prior to cementing this approach. If anyone is extremely BDD savvy, please critique. I would love to learn more.
Essentially, my unit test classes are set up to indicuate the condition, or behavior, being tested. For object instantiation, it ends up like so:
[TestClass()]
public class when_creating_a_column_from_values
{
}
and
[TestClass()]
public class when_creating_a_column_from_a_column_row
{
}
I then set up the expectations. For the constructor, the test is something like:
[TestMethod()]
public void should_create_column_object()
{
}
I then have some tests, using the same default data, for the different properties of the object. As these are business objects, the behavior is just instantiation of the objects and making sure the properties fill corretly, both from constructor and when set is called. I have worked out the tests for Column, ColumnCollection and DbTable. What is cool is I can create my test lists with the same name as the class, thus when I see a test fail, it will appear in the test runner like so )wioll get a pic later):
when_creating_a_column_from_values scale_should_be_set_to_zero
I can then discern that the scale is not zero, which will more easily lead me to the actual problem without digging too far into the test code. Thus far, it seems to be saving a bit of time, but I will defer the final analysis until I have used it for some time. I do think this way of setting up tests is clearer than the Class for Class way, ie:
[TestClass]
public class ColumnTests
{
[TestMethod]
public void ScaleTest()
{
}
}
I know that setting the Scale property failed somehow, but I am not sure what the expected outcome is without digging into the test results. Not a big deal, but I like the BDD method a bit better.
As I am seeing BDD, I can see ending up with numerous test classes, unlike the "traditional" way TDD is taught in Visual Studio (which is not a purist approach). For example, if a single object has multiple behaviors, you will have a class for each one. This is not a real issue, but it is something to consider.
As I go forward, I am wondering how I should set up my test projects. Do I group the etsts the way I do now, which is a test library for each class library project? Or, do I group behavior? Or perhaps, a library for a library, with behavior grouped in folders. So many questions. I am sure I will figure out what is most comfortable as time goes on.
Tomorrow, I will get into the meat of the application and the placement of the tests should ferret out a bit. I am going to leave a library for a library right now, with a few folders, as needed, to organize the test code. Thus far I am enjoying the paradigm shift. I need to read a bit more tonight before I go to bed.
Peace and Grace,
Greg
Stop Making Sense 