An example of bad test, part 1
Let us take a look at this test. When I saw it, the test cried out in pain to me: "Help me, I am so overworked."
This test is doing far too much. I drew the battle line on the test, just to give you a clear indication on what is going on.
What we are asserting are things that have nothing to do with what the test is supposed to test.This is also the classic "A test should have a single assertion" example, I think.
The test pass by side effect. It will actually be a problem down the line.
Comments
Ayende this is a spike, as I mentioned about 5 times on my blog and in the video. I understand the issue you're having here - I just wanted to see if it would work. It did...
Also - it's worth mentioning that I have no idea how to unit test something that is fired in an asynch way. In other words, WWF uses the WorflowRuntime, which is off on its own thread. I have a race condition in this code but believe it or not - the result came in :) and I was happy.
Now that said - what I could do is start and then stop the runtime - wait for it, and then see what the status of the order is... thoughts?
Rob,
Just to clarify.
Spike code has no standards, agreed.
It just turned out to be a good example to show bad testing practices.
Testing async code is tough.
ManualResetEvent is the common case.
Well, it looks like C#, is it?