0

I've been a (small) while (ten months more or less) doing TDD for my own applications, trying to improve my skills following this workflow. Thus I am comfortable writing tests, stubbing, mocking, etc. But what I've been noticing recently is that I prefer writing questions instead of affirmations in the tests descriptions, e.g.

describe('library', function(){
  it('How many books does it have?', function() {
    expect(library.books).to.equal(100);
  });
});

(instead of describe('library', ... it('has 100 books'...)

As when the test fails, I can see the expected and real value. I think writing questions eases the application development workflow as what you try to code is to give an answer to the test. I am aware that this method might not always be suitable, but what do you think about this?

closed as primarily opinion-based by Kilian Foth, GlenH7, durron597, Ampt, World Engineer Mar 26 '15 at 23:21

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Statements are either true or false, and are therefore simple and obvious to test. Requirements can be easily formulated as a statement, and are met when the statement is true. “The sky is blue” succeeds if the sky is blue. “Is the sky blue?” solicits a yes/no-answer, but this title does not explain what the actual requirement was. Do we test that the sky is blue or that the sky is not-blue? In your example, it's even worse, as any number would answer the question (no yes/no question). Is the requirement that the library is empty, or that it has between one hundred and one thousand books? – amon Mar 25 '15 at 11:14
5

There are many cases where you write a test that is not simply the answer to a question. Compare 'does the controller send a notification mail' with 'controller should send notification mail'. Both are valid, but it is much easier to read a list of tests formulated as 'should' rather than formulated as questions.

Another major point in TDD is that the test name should in some way indicate the nature of the test. 'how many books does it have' does nothing to indicate WHY the test is even there. 'the number of books should be equal to the number of titles times the number of copies it has' at least gives you some indication of why the test exists and what it is trying to do.

Still, your tests, above all, should be readable and allow you to pinpoint mistakes quickly. If this style is beneficial to you and the people working on your project just go ahead and use it.

3

BDD style tests (as might be the case with the framework you're using) follow the Given-When-Then convention, not Question-Answer. Depending on the approach prescribed by your testing library, shoehorning questions in there might feel awkward.

However, questions could fit well in more classical test schemes where the test description is entirely contained in the test method name.

I like the idea, not so much because you "what you try to code is to give an answer to the test" (I most often write the assertion part of the test first, and the assertion basically is the answer), but because a question-based test suite would read like an FAQ and could make requirements more easily understandable.

Not the answer you're looking for? Browse other questions tagged or ask your own question.