Tests that cannot be automatable in BDD model but can be automatable in TDD model

Question

I have been to a interview. The interviewer said they were using BDD model in their project. He asked me this question.

Define some Tests that cannot be automatable in BDD model but can be automatable in TDD model.

Does anyone know answer for this question.

Answer 1

TDD , BDD , ADD etc are just overlapping terms with only few finner difference . These differences could still be important but not so much that you should break your head over it.

TDD: test-driven development:

Here we write the tests first and then build the software to make the tests pass.

eg: see the below unit test for the class simpleCalculator

it('should return the sum of given numbers', function () {
  expect(simpleCalculator.sum(1,2)).to.equal(3);
  expect(simpleCalculator.sum(5,5)).to.equal(10);
});

we write above test first and then build the simplecalculator library and its sum method to make the test pass.

ATDD: Acceptance test driven development

This is same as TDD with more stringent "DONE" criteria . for TDD there won't proper acceptance criteria like what to test , what not to test etc . TDD covers may be the main and worse features but might miss to test some other important use cases.

ATDD avoids this issues by defining strong acceptance criteria for marking a feature as "DONE" . THe TDD tests are develped by including this acceptance criteria in test scenarios. THe acceptance criteria is defined by QA, DEv , BA and/or Product owner etc same like in BDD with none being mandatory.

eg:

it('Validate that sum method returns correct sum for positive numbers', function () {
  expect(simpleCalculator.sum(1,2)).to.equal(3);
  expect(simpleCalculator.sum(5,5)).to.equal(10);
});

it('Validate that sum method returns correct sum for negative numbers', function () {
  expect(simpleCalculator.sum(-1,-2)).to.equal(3);
  expect(simpleCalculator.sum(5,-5)).to.equal(10);
});

BDD : Behavior driven Development

This is similar to ATDD where we have well defined acceptance criteria but here instead of speaking from the product feature point of view like the method should do something. The tests are written in a view to address the behavior of the component.

like ATDD , BDD is not just about testing but also about colloborating between QA,Dev, PO and BA to come to common understanding about the behavior of a system for different conditions.All the members are mandatory in a good BDD approach.

Example of a BDD test:

eg:

    Scenario: Component tries to find sum of two numers

    Givem : Positive parameters are passed
    Then: Output should be positive

Conclusion to your question:

ATDD , BDD , TDD etc are really overlapping terms. You can have all these in any test levels like unit , integration or System. But having BDD which defines excutable specification in a lowtest level like unit test will not be benefitials due to unnecessary development effort overhead it causes. SO answer is you can use BDD for any test level but is recommended to use in Top level compoents like UI and for system test

Answer 2

I would probably answer something like this:

Personally I think BDD and TDD are nearly identical, just a slightly different way in uncovering and describing the details of the checks. Both models support the same types of checks or convince me otherwise.

BDD versus TDD. This test tool versus that test tool. Test-before versus test-after versus this-works-trust-me. At some point I got tired of the debates about details. I prefer to discuss principles.

-- Kent Beck

https://medium.com/@kentbeck_7670/programmer-test-principles-d01c064d7934

I think TDD is bigger than what most call TDD or BDD. It goes from understanding the problem till delivery of the solution. I like Steve Freeman's look on TDD the Big picture in his talk TDD this is not what we meant:

Answer 3

TDD is primarily a development technique while BDD is a way to obtain a common understanding between business, development and test.

So, what I would give is an example of a purely technical test (i.e. some type of an unit test) that wouldn't necessarily be understandable from a purely business point of view.