有关测试或单元测试的一些基本问题
所以通常我的应用程序非常小,我的测试框架只是一个控制台项目。 。我使用静态方法在其中添加类并测试我的代码。我发现这种方法非常简单而且很好(特别是因为你可以看到交付的输出)
我现在在 Visual Studio 中有一个很好的小测试项目,所以我对如何测试那些看起来不像的东西有点困惑< em>unit like,例如:
Purchase.LoadAllAsync()//finished loading on the loadcomplete event
我会为此编写什么样的单元测试?特别是因为这会根据数据库中的内容而改变?
我做了一些侦察,发现了这个: 什么时候测试不是单元测试?
这让我更加困惑,如果测试不是单元测试,你会如何测试它?
有时我通常只是在主窗体或 silverlight 主页中编写一个小测试函数,然后将其删除。但我猜使用单元测试是因为测试需要保留在那里,以便您可以重复使用它们,对吗?
对不起,如果我有点太无知了! =P
谢谢
更新
还想添加:在应用程序本身中运行良好但从外部代码调用时失败的测试怎么样? (这种情况在我身上发生过几次)你们也发生过这种情况和/或者这是否意味着糟糕的设计?
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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果您的测试取决于您无法控制的环境,那么您应该做的第一件事就是让它们处于您的控制之下:-)
换句话说,您的测试应该使用测试数据库,并且作为设置的一部分,它应该为空,然后用已知的、可预测的数据填充该数据库。或者,您可以放入存根例程并完全避免数据库访问。
非确定性测试与豆奶牛一样有用。它可能似乎有效,但不知何故结果并不如您预期的那么令人满意。
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.