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?
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.