Assert.Inconclusive and my present almost-TDD compromise

I am trying out Visual studio unit testing framework, the Microsoft alternative to, for instance, nUnit which was my old preferred testing framework (and possibly still is).

At the same time I am not in a project devoted to Test driven development so I can’t use its religion to write tests first and refuse to show any UI progress to the customer.  Right or wrong – that is how I perceive the reality around me right now.  But I do want to have tests and waiting for them I make sure I have place holders.

My compromise is to set the tests to Inconclusive  (Ignore in nUnit talk).  I guess it will come back to bite me…

What I also do is to make sure I have a test to go with every method.

        public void AddOrUpdateTest()
            Elvis.Common.Meta.GetMethodName<BLF.Sample>(x => x.AddOrUpdate(null, null));

I used the code from

but I could probably use CompulsoryCat just as well.

I belive that even adhering TDD this technique is good.  There are so many times I don’t know what the classes and methods will look like before having done a simple implementation.  To write exhaustive tests for a method that will be deleted is a waste.  Better then to make sure the simple code runs and not forget to write the tests by having a yellow Inconclusive flag.

Tags: , , , , , , ,

Leave a Reply