I realize I have been a bit quiet the past few weeks, but we just kicked off the first iteration of a new project at work, so still settling into the project groove. Luckily, the team I am on is outstanding, so there has been good progress made for the first iteration.
Now, for the real purpose of this post. I've been a TDD enthusiast for about a year now and have been reading and watching videos about BDD the past few months and I am really intrigued. I have been trying it over the past week (using Scott Bellware's SpecUnit.NET) and I have to say it feels very powerful, but there are still some disconnects for me.
First, I understand that BDD is not a new technology meant to replace TDD. It is a way of doing TDD the way TDD was meant to be done. It can help developers avoid the pitfalls of the language of TDD. When doing TDD, developers can get sucked into the mental trap of "Unit Testing". TDD is supposed to be all about setting up expectations of things the system is should do. It's not about testing to make sure that your class works as expected, or you emailing service works, etc. It's about behavior the system should have. My disconnect here is: how does that drive your design? One of the great things about TDD is that it helps you to design loosely-coupled, highly cohesive systems, because you test everything in a fine-grained way. I write a test method that tests that validates when the IsValid method is called on my domain object that it verifies valid classes and throws exceptions when the domain object does not pass validation. But it is not necessarily behavior of the system. I guess the question is, do I consider internal, technology processes behaviors as well? Even though my customer may not care that the validation method works, they only care that valid objects are saved to the persistence medium. It's a subtle difference, but when developing a large enterprise system, there are tons of internal things that may not be represented on a User Story or Scenario, but are by-products of those user stories. Maybe my observations should be more fine-grained, or maybe I just don't care about the fine-grained?
Also, how does Integration Testing fit into the BDD development cycle? Do I still do my regular NUnit integration tests? or do I assume that if my observation works as expected that my integration works? My initial thought is that my integration tests remain the same and the BDD contexts, concerns, and observations are used to verify my behaviors from an end-to-end perspective.
I would be interested in seeing how people are doing BDD. Are you doing BDD, TDD AND integration tests on your system? Do you write a failing BDD observation, then red-green-refactor TDD and Integration Tests on the component pieces till each component piece passes and then, by most accounts, your observation should pass?
Again, I have just dived into this in the last couple of weeks, and suggestions and comments are welcomed.
Thanks in advance,