How many of you have TDD or BDD in development, what exactly are you doing, when, how did you get there?

Question

Agile

I read "Flexible Testing", Xunit patterns, it's interesting who uses it and how, tried to use it, began to use it, stopped using it, and other details.

Answer 1

I haven't read the book, so I can't give an analogy. I
write in php for the web with bdd
1. I'm writing a bdd story.
(in my case, these are behat scripts)
For me, a bdd story is like functional and integration tests, in which I check the operation of my entire product as a whole.
Here he made a few rules for himself:
1.1. Be sure to formulate the goal (name) of the script
- I enter my personal account
- I create a new blog article
This will help to step back from the superfluous and not turn the script into a mess . At first, for a long time I resisted writing anything other than broadcast files in Russian. But then he smoked a chip. In fact, my scripts have turned into not just tests, but mini todo lists. Always clear and understandable.
1.2. Write in native language without technical details
And avoiding technical details helps to forget about the design of the system architecture at the stage of writing the script.
And it's much clearer to me:
- I should see "Access denied"
than
- Status page code should be 403
1.3. I (the Executor) of the script is a fool)
The script should not be tricky. From should be simple and not keep any data "in the head".
-
2. Next, I start to implement the script steps
(write tests)
- If I have a yellow (not implemented) script in my hands, then I start to think about the technical details that lie on the surface:
For example (the code provided is pseudocode for clarity
- If I have a red test in hand, then it's time for the code..
3. Writing almost all the code precedes my BDDSpec
(in my case, phpspec)
And so, I got an error from bahat.I specifically configured the utility so that it would swear
I get this error: -
uri '/new' not exist
This is a direct instruction for me to act, i.e. I have to create a new page.
Rules already exist within my system:
- a new page is a new action for the controller.
- action must return an array of values ​​for the template
Based on this, I create a specification for the controller

class ControllerSpec  {
  public function it_should_show_news ()
  {
    $this->newsAction()->shouldBeArray();
  }
}

And then the code that will pass this test:

class Controller {
  public function newsAction() 
  {
     return [];
  }
}

4. After that, by running phpspec, I got a green bddspec
5. After that, I return to bddstory again.
I get a green step
6. I return to step 2.
This is how the system begins to grow and acquire new tested functionality.
Before bdd, I used tdd with PHPUnit and was very happy until I got hooked on behat + phpspec

Answer 2

Today I found out that in one team, functional tests for the frontend are written before the implementation of features on Selenium, I'm a little shocked ..

Answer 3

Didn't read the book. In recent projects I use TDD. Stack: Yii1/2 (backend) + AngularJS (frontend) = REST. For API testing like Codeception - BDD testing framework for (in) php.
Specifically, I do the following:
1. I take a task for a new method / resource / field in the API
2. I write a test that checks the required functionality: making an HTTP request and checking the status of codes on different cases (401 / 403 / 404 / 200 etc), or checking the presence of the field and the value
3. I run the test - I make sure that it fails - there's nothing to be done, it means coding =)
4. I'm sawing the code until all the assertions turn green.
5. If necessary, I refactor.
6. Update CHANGELOG, commit, put tag, pull request.
7. I close the task, I ping the frontend.
(An additional goal - a bike that generates documentation is attached to the test run. In a nutshell - for each request-response at the time of the test run, html appears with a dump of request and response objects - thus the API has self-updating documentation. )
Analysts / managers (or who you are responsible for the requirements) configure the delivery of requirements in the form as close as possible to the test cases. In spherical vacuum BDD, the customer can formulate requirements in the form of a ready-to-use test system: Gherkin. I didn’t use it myself, but a colleague said that it was quite a working tool.
It's hard to say now how it came. Fowler advised, or Beck =)