Take the 2-minute tour ×

I just started to use TDD and it seems to be quite helpful in my case. The only thing that bothers me is that I do not see the way to mark your test as "to be implemented". While I develop an application I sometimes come up with new tests that it should pass in the future when I will be done with current changes, so I write these tests and certainly they fail as there is no such functionality yet. But as I am not going to "fix" them till I finish current part I would like to see something like yellow state (between red and green) as I would like to get red color only for broken tests and to be able to mark TODO tests with another color. Is there any practice that can help me here? I can write such tests to some kind of list but in this case it will be to double work as I will say the same first time in words and then in code.

EDIT: I just found there are todo tests in Perl standard unit framework, maybe there is something similar in Java?

share|improve this question
add comment

4 Answers

up vote 1 down vote accepted

In JUnit you can use an @Ignore annotation on the test to have the framework skip it during the run. Presuming you have a test list you could just place them in the test as follows:

@Ignore @Test public void somethingShouldHappenUnderThisCircumstance() {}

@Ignore @Test public void somethingShouldHappenUnderThatCircumstance() {}

Of course, if you don't mark them as a test in the first place you won't need the ignore. IDEs such as IntelliJ will flag ignored tests so that they stand out better.

share|improve this answer
add comment

The point of TDD is to write tests first and then keep coding until all your tests fill out. Having yellow tests might help you organize yourself, but, TDD loses some clarity with that.

share|improve this answer
Yes, maybe these tests are not part of pure TDD, but some TTDD - Todo Test Driven Development, but i am interested in a method to write them in a way that will not mix these tests with others –  Nutel May 22 '11 at 1:38
add comment

Both MSTest and NUnit for example, support an Inconclusive state, but it depends on your Test Runner as to whether these appear as Yellow in the UI. JUnit may also have support for inconclusive.

In Kent Beck's TDD by Example, he suggests writing a list of tests to write on a notepad aka a "test list". You then work on only one test at a time and progress through the list in an order that makes sense to you. It's a good approach because you might realize that some tests on your list might be unnecessary after you finish working on a test. In effect, you only write the tests (and code) that you need.

To do what you're suggesting, you would write your test list in code, naming the test methods accordingly with all the normal attributes, but the body for each test would be "Assert.Inconclusive()"

I've done this in the past, but my test body would be "Assert.Fail()". It's a matter of how you work -- I wouldn't check in my changes until all the tests passed. As asserting inconclusive is different than asserting failure, it can be used as a means to check code in to share changes without breaking the build for your entire team (depending on your build server configuration and agreed upon team process).

share|improve this answer
add comment

Perfectly alright - as long as you do not break your train of thought to go implement these new tests. You could make a note of this on your "test-list" a piece of paper OR write empty test stubs with good names and mark them up with an Ignore("Impl pending") attribute.

The NUnit GUI shows ignored tests as yellow.. so there's a good chance that JUnit does the same. You'd need the corresponding Ignore annotation to decorate your tests

share|improve this answer
add comment

Your Answer


