Posts tagged BDD
I recently listened to Jeremy Miller in the Alt.Net podcast, and I also watched the latest in the NHibernate series from TekPub. The common thread I see between both these things is the act of achievement in your own development life. Jeremy Miller talked about the state of Alt.Net and how he and others can further the cause of the movement. The main message I got was, get your house in order. Knowing who you are and what you do can go a long way in reducing the pain of development.
The TekPub series talks about NHibernate and integrating it into Rob Conery’s Kona project, but Oren Eine said something very interesting. NHibernate is a tool to keep you from doing the grunt work associated with a database. Which is exactly why I purchased the NHibernate series, I want to reduce the amount of time spent grunt working and optimize the time spent adding value.
This series of posts will be as much introspective as it is informative. I will look at things that cause me pain in my day to day development, and also explore methods to alleviate the pain (short of morphine shots).
Let’s start with the biggest area of pain, Bugs.
No software developer likes to release code that has bugs in it, but bugs are an inevitable pain every developer will have to deal with. I personally have had my fair share of bugs, but I have always been able to resolve them quickly and effectively. The pain with dealing with bugs can come from two places: the act of trying to preemptively stop them, or the act of reacting.
If you are anal about the code you write, then you probably employ some kind of testing methodology: Test Driven Development, Behavior Driven Development, Integration Testing. All These methods make sure your code works. The pain with using these methodologies is that they require a substantial amount of effort to implement. They require understanding and a time investment that some developers just don’t want to put in. I can’t say I blame anyone for not adopting a testing methodology, it takes discipline and dedication.
There are several test generating tools out there, but few really make the process any less painless. You usually are trading one set of pros and cons for another. The trick here is to build a system of developing tests regardless of tools you use. A system that is smaller in complexity is ideal. Test Driven Development has Red Green Development; a process where you get tests to fail then pass. A small but effective system of writing tests. A solid system can help bake practices in and make you more disciplined.
After understanding why I should write tests, I found that bugs in my code are melting away. It’s hard to make a test pass when all your assumptions are correct but the code isn’t. So am I saying that everyone should adopt a testing methodology? No I’m not, but I do recommend it to those developers who don’t like dealing with bugs later because it can substantially reduce those incidents.
So you’ve spent the time to write tests, but bugs still creep into your code. Time to panic! Aaaaah!
I’ve seen this one too often. A bug is found and everyone goes into fire-drill mode. Managers hovering, programmers sweating, IT guys pushing continual updates. It is like watching a slow motion crash test. The problem usually get’s fixed, but not the best way. In addition, the fix usually introduces more bugs.
The solution here is to understand what is happening. Far too often, companies feel that panic mode is ok but it psychologically drains everyone involved. This can bring morale down and breed resentment amongst groups. Why didn’t the testers catch that major bug? How could the programmers have been so stupid? Why are the managers making me push a solution every 5 minutes? What happened to the order of things?
So how do you reduce this pain. Well I’ve experimented with a few options and found that sandboxing is the best course of action. A sandbox environment that is exactly like your production environment. This might seem obvious but the number one sin that most people commit is, they don’t respect the concept of those environment. A sandbox should be your first and only place you push code. Once you are happy, copy that exact environment over to production. There should never be any code directly pushed to production. Respect the structure you setup and it will help you, don’t respect it and it will come back to haunt you.
Beta environments are also a good way to reduce the pressure of critical bugs. Many application have employed this method with success. Create a clone of your web application/application that is strictly Beta. There is an implied agreement between you and your users that there are bugs and the experience might not be ideal. That way you won’t be surprised when a critical bug occurs, also your clients will hopefully understand why the application broke.
Bugs are a part of our development life. They are present and they will always be there. The best thing we can do is take an approach that makes it less painful in our development lives. Some developers are more comfortable writing tests to preemptively stomp bugs, while others thrive in the panicked environment of critical bugs. I personally feel that I don’t want to let bugs get out the door, so I test everything with a three pronged approach. Unit Testing, Integration Testing, and Quality Assurance.
For me software development has become more than just writing code, although ultimately that is what it’s about; a developer writing applications that work and serve a function. As I’ve progressed through my development life, I have picked up techniques and methodologies to help me develop a better application. Some of these techniques are Domain Driven Design (DDD), Behavior Driven Development (BDD), and Test Driven Development (TDD). Jeez that’s a lot of D’s! What’s the difference between all of these methodologies and when to use them? Well I’m about to tell you where they fit into my development ecosystem. Again, this is where I’ve found these methodologies to work the best for me.
Domain Driven Design (DDD)
I’ve always thought of DDD as a mindset rather than a code writing methodology. DDD’s main focus is create a dialogue between developers and the domain they are attempting to develop in. For example, if I were writing a blog, then my discussions and inevitably my code would include words like “posts”, “tags”, and “categories”. I’ve always found DDD to be easy for developers to understand. It doesn’t require any tools except for a good whiteboard and some developers willing to talk to each other and their business partners. Below are the necessities that I perceive to properly implement DDD.
- Open dialogue
- Domain experts
- An open mind
Behavior Driven Development (BDD)
I use BDD to express my application’s intent (with code) within my project. The specifications are written using stories and scenarios, and it is my job to make sure that those stories are true through functionality. BDD is cool because intentions are visible, and all your BDD stories are written in English that is understandable to your domain experts. BDD and DDD are tightly interlocked because your stories will most likely come out of your DDD sessions with your domain experts. Below are a overview of the tools needed to implement BDD.
- BDD Framework (For .Net : MSPEC, StoryQ, SpecUnit.Net, SpecFlow)
- Story (Test) Runner
- Discipline of Steel ( the most important thing)
Test Driven Development (TDD)
I still use test driven development, but in a different scope. TDD has turned into my debugging approach of choice when dealing with a client’s code. I attempt to write a unit test to isolate issues. During this process, I can re-factor and learn more about the newly presented code base. Once I can reproduce the bug through a unit test, I can start thinking about what I need to do to solve the issue. This method of debugging only works with code based bugs, and not things like memory leaks.
- TDD Framework (For .Net : NUnit, xUnit, MbUnit)
- Test Runner
- Ability to reverse engineer
As you see above, all these methodologies are alive and well in my development ecosystem and they all play overlapping roles. The thing to keep in mind is that there isn’t a point where I say “I am going to do BDD now!” or “It’s time for some DDD!” These methodologies are applied fluidly but precisely. I cannot stress enough that self discipline is at the foundation of any methodology you use. If you don’t believe enough in the methodology to follow it’s main tenants, then you’ll find yourself undermining your own efforts. At the end of the day, a methodology is a system, a series of steps that you take to develop an application; respecting that system can yield great results.