title: Is Assert.Fail() considered bad practice?
body: <p>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.</p>
  
  <p>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?</p>
  
  <hr>
  
  <p>@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.</p>
  
  <p>@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.</p>
  
  <p>@Matt Howells
  Great Idea. NotImplementedException communicates intention better than assert.Fail() in this case</p>
  
  <p>@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.</p>