问题标签 [tdd]

作为一名实践测试驱动开发的新手，我经常陷入困境，即如何对数据库的持久性进行单元测试。

我知道从技术上讲这将是一个集成测试（不是单元测试），但我想找出以下最佳策略：

1. 测试查询。
2. 测试插入。如果插入失败，我怎么知道插入出错了？我可以通过插入然后查询来测试它，但是我怎么知道查询没有错呢？
3. 测试更新和删除——与测试插入相同

做这些的最佳实践是什么？

关于测试 SQL：我知道这可以完成，但是如果我使用像 NHibernate 这样的 O/R 映射器，它会在用于输出查询的别名中附加一些命名疣，因为这有点不可预测，我不确定我可以对此进行测试。

我应该放弃一切并简单地信任NHibernate吗？我不确定这是否谨慎。

我希望在我的应用程序中添加一个测试套件，但是我无法迁移到 .NET 3.5 的更新测试框架。

有人对使用好的测试框架有什么建议吗？

过去几年，测试驱动开发在 .NET 社区中风靡一时。最近，我在 ALT.NET 社区中听到关于 BDD 的抱怨。它是什么？它与 TDD 有何不同？

我创建了一些 MbUnit 测试装置，它们的 SetUp 方法用 SetUp 属性标记。这些方法使用 MbUnit GUI、控制台运行器和 ReSharper MbUnit 插件在测试之前运行良好。但是，当我使用 TestDriven.NET 运行测试时，它根本不运行 SetUp 方法。

有谁知道这是 TestDriven.NET 的错误还是我的设置有误？

很多人在开始编写代码之前谈论为他们的代码编写测试。这种做法通常被称为测试驱动开发或简称 TDD。以这种方式编写软件对我有什么好处？我如何开始这种做法？

模拟密封类可能会很痛苦。我目前喜欢使用适配器模式来处理这个问题，但有些东西总是让人感觉很奇怪。

那么，模拟密封类的最佳方式是什么？

Java 答案非常受欢迎。事实上，我预计 Java 社区处理这个问题的时间会更长，并且可以提供很多东西。

但这里有一些 .NET 意见：

• 为什么 Duck 类型对 C# 开发人员很重要
• 为密封和其他模拟类型创建包装器
• WCF（和 Moq）的单元测试

What is the best way of testing a function that throws on failure? Or testing a function that is fairly immune to failure?

For instance; I have a I/O Completion Port class that throws in the constructor if it can't initialise the port correctly. This uses the Win32 function of CreateIoCompletionPort in the initialiser list. If the handle isn't set correctly - a non-null value - then the constructor will throw an exception. I have never seen this function fail.

I am pretty certain that this (and other functions like it in my code) if they fail will behave correctly, the code is 50 lines long including white-space, so my questions are

a) is it worth testing that it will throw
b) and if it is worth testing, how to?
c) should simple wrapper classes as these be unit-tested?

For b) I thought about overriding CreateIoCompletionPort and passing the values through. In the unit test override it and cause it to return 0 when a certain value is passed in. However since this is used in the constructor then this needs to be static. Does this seem valid or not?

在我最常使用的 C++ 项目中，我大量使用了 ASSERTION 语句，如下所示：

但是 TDD 社区似乎喜欢做这样的事情：

仅凭我的经验，第一种方法就让我消除了许多微妙的错误。但是 TDD 方法是处理遗留代码的非常聪明的想法。

“Google”——他们将“FIRST METHOD”比作“穿着救生衣走在岸边，在没有任何安全防护的情况下畅游大海”。

哪一个更好？哪一个使软件健壮？

单元测试和 ASP.NET Web 应用程序在我的小组中是一个模棱两可的点。通常情况下，良好的测试实践会落空，Web 应用程序最终会在没有测试的情况下运行数年。

造成这个痛点的原因一般都围绕着在开发过程中编写 UI 自动化的麻烦。

您或您的组织如何将最佳 TDD 实践与 Web 应用程序开发相结合？

I'm familiar with TDD and use it in both my workplace and my home-brewed web applications. However, every time I have used TDD in a web application, I have had the luxury of having full access to the web server. That means that I can update the server then run my unit tests directly from the server. My question is, if you are using a third party web host, how do you run your unit tests on them?

You could argue that if your app is designed well and your build process is sound and automated, that running unit tests on your production server isn't necessary, but personally I like the peace of mind in knowing that everything is still "green" after a major update.

For everyone who has responded with "just test before you deploy" and "don't you have a staging server?", I understand where you're coming from. I do have a staging server and a CI process set up. My unit tests do run and I make sure they all pass before an an update to production.

I realize that in a perfect world I wouldn't be concerned with this. But I've seen it happen before. If a file is left out of the update or a SQL script isn't run, the effects are immediately apparent when running your unit tests but can go unnoticed for quite some time without them.

What I'm asking here is if there is any way, if only to satisfy my own compulsive desires, to run a unit test on a server that I cannot install applications on or remote into (e.g. one which I will only have FTP access to in order to update files)?