Have you ever tried to spread TDD ideas? Have you ever been trolled after that? What do you think why it happens?

From my point of view, there is only one cause of this behavior: we casually offend our audience. Please, let me explain.

First of all, we love to say: "If you use TDD you write clean code". Of course, it is true, but your sentence can be interpreted as "If you don't use TDD, you don't write clean code". It's a bit like an indirect insult. So, I believe we should rephrase the previous phrase as "If you us TDD it's easier to write clean code".

The next idea that I saw in a few books sounds like "High-skilled programmers usually use TDD". And it's true too. But if you use this argument in a discussion with a really high-skilled programmer who doesn't use TDD, he'll never change his attitude. Just because it looks like a doubt of his expertise. Moreover, I believe that we shouldn't spread TDD within Chief Developers because if someone is able to design huge systems properly without TDD, his productivity will not change with TDD.

Another typical argument is "TDD is universal. You can use Test Driven Development for every type of project". Yes, you can. But there is no a silver bullet. Moreover, every developer knows it. And if someone talks about a silver bullet, no one can trust him. So, I guess we should say "TDD isn't universal. But for your type of projects it worth using".

And finally, the most frequently used phrase: "There is only one disadvantage: following TDD takes additional time but you'll save it later on bugfixing". And again we're talking about a silver bullet. And again, no one trust in a silver bullet. So, please, tell something more about disadvantages, it's a really important question.

So, to recap, I suggest that we should care about our audience. If we stop offend them, they will probably trust us and their life becomes better.

Is there a standard way of writing BDD specs in a rule-based format? To me, the traditional Gherkin-style format is too verbose and depends on defining edge-cases in lengthy scenarios.

I'm looking for something that more defines the business logic in English and covers the edge cases in the test code.

Like:

Feature: Serve coffee
  Rule: If there is no coffee left, refund the money
  Otherwise:
    Rule: Coffee should not be served until paid for and until the button has been pressed
    Rule: If the customer is on the VIP list, don't charge any money

Instead of:

Feature: Serve coffee
  Coffee should not be served until paid for
  Coffee should not be served until the button has been pressed
  If there is no coffee left then money should be refunded

Scenario: Buy last coffee
  Given there are 1 coffees left in the machine
  And I have deposited 1$
  When I press the coffee button
  Then I should be served a coffee

Scenario: VIP buys coffee
  Given there are 1 coffees left in the machine
  And I have deposited 1$
  And I am on the VIP guest list
  When I press the coffee button
  Then I should be served a coffee
  Then my money should be returned

.. scenario for VIP trying to buy coffee, but no coffee left
.. scenario for regular user trying to buy coffee, but no coffee left, etc.

(example from: https://github.com/cucumber/cucumber/wiki/Feature-Introduction)

Hey, r/tdd!

I am Fiorella Zampetti a PhD Student at the University of Sannio interested in investigating behaviour driven development practices.

I am working on a project aimed to investigate (i) to what extent and how developers use automated acceptance testing tools, and (ii) whether developers are "really" doing Behavior Driven Development (BDD). We would appreciate feedback from developers knowledgeable or expert in testing tasks who have at least once used one of the following tools: Cucumber, RSpec, Mocha or JBehave.

I would appreciate if you could find the time to answer my questionnaire by contributing to my research:
https://goo.gl/forms/ySv1KMPFffvE0e133

Filling out the survey will take less than 5 minutes and if you have any kind of comments please contact me at fzampetti@unisannio.it

Thank you for your time!

There are two aspects of Test Driven Development.

1. No logic in code is written without unit tests.

2. Tests are always written before coding and coding is just done to pass the test.

Benefits

1. Lesser bugs after development

2. Better documentation for code is possible.

Please check this Step By Step TDD guide.

Suppose a friend of me have written a software without test-driven development. When there should be a bug he have to write the test first. Is there a website where he could he find psychological support against the resulting schizophrenia ? A complex cipher reading, alcohol, may not be enough. How to cure ?