Question: I use Assert.Fail a lot when doing TDD. I'm usually working on one test at a time but when I get ideas for things I want to implement later I quickly write an empty test where the name of the test method indicates what I want to implement as sort of a todo-list. To make sure I don't forget I put an Assert.Fail() in the body.

When trying out xUnit.Net I found they hadn't implemented Assert.Fail. Of course you can always Assert.IsTrue(false) but this doesn't communicate my intention as well. I got the impression Assert.Fail wasn't implemented on purpose. Is this considered bad practice? If so why?

---

@Martin Meredith
That's not exactly what I do. I do write a test first and then implement code to make it work. Usually I think of several tests at once. Or I think about a test to write when I'm working on something else. That's when I write an empty failing test to remember. By the time I get to writing the test I neatly work test-first.

@Jimmeh
That looks like a good idea. Ignored tests don't fail but they still show up in a separate list. Have to try that out.

@Matt Howells
Great Idea. NotImplementedException communicates intention better than assert.Fail() in this case

@Mitch Wheat
That's what I was looking for. It seems it was left out to prevent it being abused in another way I abuse it.

Answer: 
It was deliberately left out. This is Brad Wilson's reply as to why is there no Assert.Fail():

> 
> We didn't overlook this, actually. I
>  find Assert.Fail is a crutch which
>  implies that there is probably an
>  assertion missing. Sometimes it's just
>  the way the test is structured, and
>  sometimes it's because Assert could
>  use another assertion.
> 
> 
>
Why would you use `Assert.Fail` for saying that an exception should be thrown? That is unnecessary. Why not just use the `ExpectedException` attribute?