2

So usually my apps are very small and my test framework is just a console project. . I add classes in there with static methods and test my code. I find this approach to be pretty straightforward and nice (especially since you can see the output delivered)

I have a nice little test project in visual studio now, so I was a little confused about how you would test things that don't seem unit like, for example :

Purchase.LoadAllAsync()//finished loading on the loadcomplete event

What kind of unit test would I write for this? Especially because this would change based on whats in the database?

I did some scouting on SO and found this : When is a Test not a Unit-test?

Which confused me further, if a test is not a unit test, how would you test it?

Sometimes I usually just write a small test function in the main form, or mainpage in silverlight and then just delete it off. But I guess unit testing is used because the tests need to stay there so you can re-use them right?

Im sorry if im a little too ignorant! =P
Thanks

Update

Also wanted to add: What about tests that run fine in the application itself, but when called from external code it fails. (This has happened to me a couple of times) Does it happen to you guys too and/or does it mean bad design?

Community
  • 1
  • 1
gideon
  • 19,329
  • 11
  • 72
  • 113

1 Answers1

5

If your tests depend on circumstances outside your control, the first thing you should do is get them under your control :-)

In other words, your test should use a testing database and, as part of the setup, it should empty then populate that database with known, predictable data. Alternatively, you can put in stub routines and avoid database access altogether.

A non-deterministic test is about as useful as a soy-milk cow. It may seem to be working but somehow the results aren't as satisfying as you expected.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • ok what about the Async method? How would I assert what it loads, when it loads up later? – gideon Nov 22 '10 at 07:58
  • 1
    If it's async, you need to check immediate return then either (1) capture an async-operation-complete indication at some point (with a suitable timeout) or (2) check periodically to see that it eventually loads up the data (again with a timeout). Since an async operation isn't very useful without indication, (1) is probably the most likely case but you may have to use (2) if needs require. – paxdiablo Nov 22 '10 at 08:02
  • @paxdiablo how would (1) work in visual studios unit test env? A unit test is just one static method right? – gideon Nov 22 '10 at 08:11
  • No idea, @giddy, I'm not au fait with VS. However, if you're limited by the unit testing framework, there's not much that you can do other than kludge it up. You may want to think about having a separate test for _calling_ loadasync (which returns success when that returns) followed by a test which waits a suitable amount of time then checks the DB for correctly loaded data. But again, whether that's possible with your particular unit testing framework, I don't know. – paxdiablo Nov 22 '10 at 08:14
  • @pax oh boy! I added a silverlight test project, and now an async load method that i *know* works, fails to load, and never hits the complete event! =S lol – gideon Nov 22 '10 at 08:37
  • @pax So heres another problem, the test works perfectly fine in the application itself, but when the code is called externally it fails! lol Does that mean things are not well coded or does this kinda thing happen? – gideon Nov 22 '10 at 08:46