Skip to main content

Why TDD always fail?

Last post 07:31 am May 6, 2016 by Piotr Gorak
5 replies
02:08 am April 28, 2016

Is this because the prod code has not been checked in or the prod code does not exist yet or because automated test harness has to ran?

I would incline to say prod code does not exist ... thoughts?


04:53 pm April 30, 2016

What do you understand by TDD?


02:34 am May 2, 2016

TDD is test driven development. The question was very ambiguous. When I work in a TDD environment I checkin.my unit test first. It fails because I have not checked in my prod code.


09:30 am May 2, 2016

Hi Am,

A couple of days ago I came across the following post on Uncle Bob's blog. Maybe it will provide you with the answers you are looking for: http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html

A test first approach requires that the tests should be written before proceeding with the actual code. In short you should follow the principle "Red-Green-Refactor".


09:51 pm May 2, 2016

A test first approach means that you write tests before you write the code. It doesn't mean you check in the tests before writing code.

Write your test, write code for it. Write more test, and write the code. Repeat that until the task is done, and then you check in the whole code. ;)


07:31 am May 6, 2016

Let me try structuring the answer better...

In TDD we write ONE test first (not tests (pl)), we see it failing, we write the minimum code for the test to pass. If it passes, we ask ourselves a question: is there anything in what's just been written that needs to be re-factored? If so, we do the refactoring trying to keep the unit tests (pl) passing. When everything is green, we start with next test.

Once you completed one "loop" of TDD, nothing blocks you from committing your change so that it is visible to everyone. Yes, you CAN and in some circumstances you even should commit the unfinished work, as long as the tests are green. There is no rule requiring you to wait until "the whole story is completed", etc. But there is also no strict rule that you must commit after EVERY loop.

Other thing is, depending on the version control tool you are using, commit may have different meaning for you. In Git, for example, you commit to your local repository and it is actually the "push" command that causes your changes to appear in the main repository so other can see them. For this thread, I assumed the word "commit" means "make change visible to everyone".

Piotr


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.