In TDD the test always fails at the start because
A) The quality of Code is bad
B) The developers don’t know the functionality
C) The developers can not test
D) There is no code
asked Feb 2, 2017 at 4:54
-
4What is this? A certificate exam question?– Yu ZhangCommented Feb 2, 2017 at 7:15
-
Trying to understand TDD and it's whys, whats and hows!– IAmMilinPatelCommented Feb 2, 2017 at 7:17
-
2The whole question is very imprecise. TDD is used in unit tests and for the test to compile the API under tests it calls must be available. If it is not available the test won't compile (at least in languages I work with). I guess the assumption should be that at least an empty API method is available. The answer D is quite close here, but's still impresice: when you have API to call, it means there's already some code.– dzieciouCommented Feb 2, 2017 at 8:59
-
1Not if your first test is an end-to-end like test, it will just fail because the end-point is not there. You do not need any code for your first working failing test.– Niels van ReijmersdalCommented Feb 2, 2017 at 10:59
-
One of the hallmarks of a good SE post is documenting the attempt at an answer. I don't have a problem with a multiple choice question, but this doesn't show what you've done to solve the problem yourself.– corsiKa ♦Commented Feb 6, 2017 at 23:43
|
Show 1 more comment
2 Answers
D) There is no code
This is the one and only correct answer because the idea of TDD is that you only implement code for which you have a failing test. It prevents you from implementing things you do not yet need. This comes from one of the ExtremeProgramming practises YAGNI.
One way XP’ers would keep themselves honest is to insist they write a failing unit test (demonstrating the need for complexity) BEFORE adding the extra complexity to the system.
Failing test example:
Steps for a failing tests are:
- Declare & Name
- Write test Arrange/Act/Assert parts
- Satisfy compiler
- Verify it fails by running it
Now you can start writing your code.
Background from the XP website:
When you create your tests first, before the code, you will find it much easier and faster to create your code.
Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.
Learning & practise TDD:
Anyone interested in TDD should watch the theory and practise the examples described in the Coding Dojo TDD PluralSight video, preferable in a group setting. It will learn you which skills are required for TDD and practise them.
The learning starts with TDD kata's like the string calculator and or the bowling game.
Other reads:
answered Feb 2, 2017 at 8:22
-
If there is no code than the test may not compile. It will have no chance to fail at all ;-)– dzieciouCommented Feb 2, 2017 at 9:09
-
3In TDD the failing test contains just enough production code to compile, for example an empty class. Added the steps for a failing test in TDD, which contain Satisfy compiler. Commented Feb 2, 2017 at 9:22
-
I agree, but the question doesn't say there's empty class. It says: "There is no code". This is why I think exam questions are silly if context is not explained or they are so generic.– dzieciouCommented Feb 2, 2017 at 9:30
-
Normally you start without any code when you write your first failing test, this is part of TDD. I would start with a higher level integration or UI test that fails for example because the website is not there yet. From there you start writing smaller unit-tests until you fulfill your high-level test. A/B/C have nothing todo with TDD at all. Personally I think D fits the TDD concepts even if is a bit text-book like without enough context. Watch Steve Freemans TDD (that's not what we meant) video, he shows the big picture where you start with a failing end-to-end test without any code. Commented Feb 2, 2017 at 9:37
TDD, test driven development. From my personal experiences, it has the following characteristics:
- Development starts the same time with test developments, from the very beginning of development cycle
- Tests are written for features that have not been properly developed / implemented yet, e.g. an automated test script verifies if the output of a feature is within 5~99, integers only.
- Automated tests start running, of course, they will fail initially as the feature has not been implemented yet OR not working properly.
- Developers write their codes to produce an output between 5~99, automated tests are executed on a regular basis.
- TDD tests will pass once the feature is implemented properly.
- END
A) The quality of Code is bad
- It is a possibility, but how "bad" it is? Does it produce unexpected behavior?
B) The developers don’t know the functionality
- It is possible too, if the developers do not know the functionality, they may not be able to produce the expected output hence TDD will fail.
C) The developers can not test
- This is unlikely to be the answer.
D) There is no code
- It is possible too, no code = no output, TDD tests will always fail. But this answer is way too obvious to be true IMO.
My money is on B
-
Sorry had to downvote, because B means you should not even start coding, because if you do not understand why and what your building start talking to your PO/Customers first. If you already have functionality then it should already have tests. If you do not think D is the answer I think you should do some more research into TDD and where it came from. Commented Feb 2, 2017 at 8:29
-
Although D) is the "answer", B) is also the answer when you look at the big picture / long term. At the heart of Agile development is the acceptance that your users don't actually know the functionality they want until they start seeing parts of it. It's part of the humility required for Agile. However in the context of this question this is too subtle and so again the answer is A Commented Jan 5, 2021 at 13:21