When Behaviour Driven Development Goes Wrong
Fleeting- Référence externe :
- see,
for me the core idea here is that we aim to separate the specification of our systems from their implementation we want to describe what we’d like our system to do without saying anything at all about how it does it as far as we can at least if we can do this we gain some huge advantages it means that we need to be able to describe clearly what our system needs to do so we need to collaborate with people who understand the problem that we’re working on we need to record what we learn from these collaborations in a way that helps us to steer our development efforts effectively
—
more general mistake testing implementation and not specifying behavior
—
this is a big mistake our job as software developers is not typing code it’s solving problems with software if you think that your job is only typing code i’d recommend that you take a look at what github’s ai based copilot can do at the moment it may make you nervous about your job
—
you don’t get to understand the problem if the requirements only say things like put a button here or add a service there
—
whoever wrote this real specification was thinking of it as some kind of test rather than as a specification they were probably also thinking something like it’s taken me all this time to get to this point so may i may as well try everything that i can think of while i’m here this makes the test fragile a tiny change will invalidate it it obscures the real requirements
—
it’s easy to mistake bdd scenarios for tests i often refer to them as acceptance tests but their real job is to define the behavior that we want from our system to act as an executable specification that will guide our development and then only later verify test that our system meets its specifications the real behavior
—
nice suggestion for checking that you have your specifications right can you imagine your specification working as an example in the documentation of your system
—
scenario overload this is often caused by people using bdd as the only form of automated testing for their system or when these bdd scenarios are left to a QA team to write and maintain separately from a development team in both of these cases the people writing the tests try to make sure that every possible case is covered that’s not really the job of these specifications
—
all of the parts of the name matter in behavior-driven development software development driven by focusing on the desired behavior of the system we want high level executable specifications that drive our development process from the outside in based on a laser focus on the desirable behaviors that we’d like our system to exhibit it’s not our aim to test every conceivable input to our systems here executable specifications work best in combinations with other forms of automated testing so try to avoid over testing in bdd scenarios my preferred approach to bdd is to deploy my software into a production-like test environment that runs a series of realistic scenarios that demonstrate the behavior of the system from the perspective of an external user
—