Is it about regression testing or is it about BDD?

Let's make one thing clear. Tools are not to redeem you from any harm. They are not the solution to your unbalanced coding process! In fact, you have to make sure your creating software like there are no tools at all. And then think again: is my software up against changes? Am I on the right track for clean code or am I trying to consciously balancing the solution on the edge of the abyss? Don't depend on unit testing as the only world saving tooling! Be smart!

You have to admit, there is a leak in this utopia, cause we provide automation to our customers. Thus if we are specialized to do that, we are fooling ourselves if we denied our nature: we are as lazy as the customer. Maybe lazier than they are. So testing isn't so bad at all. So let's differentiate a bit shall we?

Why do we want to test our software? First of all, you want to make your code transparent to all of your colleagues. They need to know exactly what it is doing and how it is working. If they can't understand it then possibly two things are going on. Either your colleague is not capable of reading code or you have fallen short in writing it well. Second, we are not infallible, as much as we like to think of ourselves. (I know we do: we all like to be liked and we like to pretend to be someone who doesn't make mistakes or less then anyone else. It's like we all are better then the average, which can't be true, because then the average is lifted) And despite our effort and our knowledge, we all do make mistakes. That's not bad. In fact, that's good and its reality. So don't worry about that and don't worry our managers worry. That's the point where tests come in and assist you. They help you when you starting to fail. It's obvious that you can't think about all things at ones. Even the best programmers aren't flawlessly programming and so you are not. So let's move on to something I forgot to mention.

Two steps back!

Before you create good code there must be something done in advance. As a developer we think that we are so good at solving a problem and creating a solution, we forget what we really are. We are ordinary human beings. So erase the image of the superhero you think you are. (Mmm, isn't that the reason we give our teams such graceful names like 'Men in Black' or 'The Avengers'?) What we need to do is acknowledge we can not write clean code on our own and we don't come up with the best solution on our own. We need someone else, or more than someone else. We need our fellow developer to challenge problems. (Off the record, I'm not consistent with the word 'problem'. This is why: you need to put things in perspective! My mind is forecasting a situation. If reality is different, then I experience it as not acceptable and I am creating my own problem. If I adjust my perception, then I accept the effects of the situation more easily. But lets resume this epistle, shall we?) If we collaborate with our colleague developers we earn synergy! And if we let customers (or on-site customers) involve, we know exactly that the ideas we come up with are fruitful and honest. And that's when we talk about BDD.

BDD is not a tool, it's a mindset. BDD forces you to talk to the customer (in any form) and create scenario's to evaluate the solutions we had in mind. And the beautiful thing here is that the scenario's extent the range in clearly thinking. Scenario's point out the real meaning and rule out mistakes. And it helps you to see the right objects through writing variants, like abstractions and loose couplings etc.

Summary

Let's make a summary of BDD and scenario's. Scenario's will help you with:

• extending your thinking range
• earning synergy by discussing them with your colleagues and/or customers
• seeing abstractions and creating maintainable code
• point out the true meaning of the feature
• rule out mistakes, like misinterpretation or bad paths
• behavior documentation
• unit tests

SpecFlow is a little of a side path in this story. It is based on BDD-scenario's but eventually it has nothing to do with BDD at all. Let's not mis interpertate SpecFlow on that. SpecFlow only let your scenarios fit on a unit test. It's an adapter.

This blog originated from a discussion about how to test our software. In the next blog I'll talk about testing UI and web-api's and what you should test about them.