Part of the joy of BDD is moving away from that word, "test".
Instead, we have examples which illustrate how the code behaves, both at a system and a unit level.
Those examples let us question whether the behavior of the code is appropriate. For instance, we might have a "Shop" class which is responsible for recording stock, as well as for taking orders.
When we look at the examples, we can see the following behaviors illustrated:
should Record Stock
should Take Orders
One of the things we can do when we stop thinking about "tests" is think, "should it? Should it really?"
We can see that these are two different aspects of behaviour, so we know that maybe the shop should delegate those aspects. We can start thinking about what a shop should really do.
What's the purpose of a shop? Well, it's to make money for the owner, and to provide goods for customers. Recording stock and taking orders are just part of that.
So maybe a shop:
should Make Money
should Provide Goods for Customers
Wow. We've got the ability to take orders and to record stock, but we haven't actually got any way of finding out if we're making money or providing the correct goods. Maybe we should do that, too...
By using natural language, and talking about what a piece of code should do, we can have conversations with our business to see if we understand their requirements correctly, then carry the language they use into the code.
At that point, a lot of things become more obvious.
- If our code isn't doing what it says it should, it might be the wrong code.
- If our code is doing what it should, but doesn't say it's doing it, we need to refactor things like method and variable names, and maybe extract some methods too.
- If something else should be doing what our code is doing, we need to move things into different classes.
- If our application isn't doing what it should, we can have a chat with the business about what they really want it to do instead.
Using a shop is a pretty simple example, but I hope you can see that by thinking of code not in terms of "test" and "how to test", but in terms of "how it should behave", we end up using the Single Responsibility Principle... well, more responsibly. And we probably learn a lot about our domain, while creating readable and maintainable code, at the same time.
This is the heart of BDD. I find that experienced BDDers tend to need to refactor less, because they end up creating things that adhere to the SRP to begin with.