问我是不是不理解测试驱动开发单元测试(Asp.Net MVC项目)？

EN

我正在尝试弄清楚如何正确有效地对我的Asp.net MVC项目进行单元测试。当我开始这个项目时，我买了project，通过这本书，我了解了ASP.Net和单元测试。在看过这些例子后，以及我在目前的公司做QA软件工程师的事实，我对TDD看起来有多棒感到惊讶。因此，我开始着手我的项目，开始为我的数据库层、业务层和控制器编写单元测试。在实现之前，一切都经过了单元测试。起初我认为这很棒，但后来事情开始走下坡路。

以下是我开始遇到的问题：

• I最终编写了应用程序代码，以便能够执行单元测试。我的意思不是好的，因为我的代码坏了，我必须修复它，这样单元测试才能通过。我的意思是，将数据库抽象为模拟数据库是不可能的，因为使用linq进行数据检索(使用通用存储库模式).The原因是，使用linq->sql或linq->实体，您只需执行以下操作即可进行连接：

var objs = select p _container.Projects select p.Objects；

但是，如果您模拟数据库层，为了使linq通过单元测试，您必须将linq更改为

var objs = select p from _container.Projects join o in _container.Objects on o.ProjectId等于p.Id select o；

这不仅意味着你正在改变你的应用程序逻辑以便你可以对它进行单元测试，而且你正在为了可测试性而降低你的代码的效率，并且摆脱了在第一个place.Furthermore中使用ORM的许多优点，因为我的模型的许多I都是数据库生成的，我证明了必须编写额外的代码来处理非数据库测试，因为I从来没有生成过，我仍然必须处理这些情况才能让单元测试通过，然而它们永远不会在真实的场景中发生。

因此，我最终放弃了我的数据库单元测试。只要我返回视图，

• 为控制器编写单元测试就很容易。但是，我的应用程序的主要部分(也是从单元测试中获益最多的部分)是一个复杂的ajax web应用程序。出于各种原因，我决定将应用程序从返回视图更改为返回包含所需数据的JSON。在这种情况发生后，我的单元测试变得非常痛苦，因为我还没有找到任何好的方法来为非平凡的json.After编写单元测试，这让我头疼，浪费了大量的时间试图找到一个好的方法来对JSON进行单元测试，我放弃并删除了所有的控制器单元测试(到目前为止，所有的控制器操作都集中在应用程序的这一部分)。

• ，所以最后我只剩下测试服务层(BLL)了。现在我正在使用EF4，但是我在linq->sql上也遇到了这个问题。我选择了EF4模型优先的方法，因为对我来说，这样做是有意义的(定义我的业务对象，让框架找出如何将其转换为sql后端)。这在一开始是很好的，但现在变得很麻烦，因为例如我有Project、User和Object实体。一个对象必须关联到一个项目，一个项目必须关联到一个用户。这不仅仅是特定于数据库的规则，这些也是我的业务规则。但是，假设我想做一个能够保存对象的单元测试(举个简单的例子)。我现在必须执行以下代码，以确保保存工作正常：

User usr =新建用户{ Name = "Me“}；_userService.SaveUser( usr )；Project prj =新建项目{ Name =”测试项目“，所有者=usr }；_projectService.SaveProject(prj)；Object obj =新建对象{ Name =”测试对象“}；_objectService.SaveObject(obj)；//进行验证

仅仅为了执行一次单元测试就必须执行所有这些操作，这会带来很多问题。这有几个问题。

- For starters, if I add a new dependency, such as all projects must belong to a category, I must go into EVERY single unit test that references a project, add code to save the category then add code to add the category to the project.  This can be a HUGE effort down the road for a very simple business logic change, and yet almost none of the unit tests I will be modifying for this requirement are actually meant to test that feature/requirement.
- If I then add verifications to my SaveProject method, so that projects cannot be saved unless they have a name with at least 5 characters, I then have to go through every Object and Project unit test to make sure that the new requirement doesn't make any unrelated unit tests fail.
- If there is an issue in the `UserService.SaveUser()` method it will cause all project, and object unit tests to fail and it the cause won't be immediately noticeable without having to dig through the exceptions.

​

因此，我已经从我的项目中删除了所有服务层单元测试。

我可以继续下去，但到目前为止，我还没有看到单元测试有任何方法可以真正帮助我，而不是妨碍我。我可以看到我可以实现单元测试的特定案例，例如确保我的数据验证方法正确工作，但这些案例很少。我的一些问题可能可以减轻，但不能不向我的应用程序添加额外的层，从而使更多的故障点，以便我可以单元测试。

​

因此，我的代码中没有留下单元测试。幸运的是，我大量使用源代码控制，所以如果我需要的话，我可以把它们拿回来，但我就是看不到这一点。

在互联网上到处都可以看到人们在谈论TDD单元测试有多棒，我不仅仅是在谈论那些狂热的人。少数对TDD/单元测试不屑一顾的人给出了糟糕的论据，声称他们通过IDE手动调试更有效，或者他们的编码技能令人惊叹，因为他们不需要它。我认识到这两个论点都是彻头彻尾的论据，特别是对于一个需要由多个开发人员维护的项目来说，但任何对TDD的有效反驳似乎都很少。

所以这篇文章的重点是要问，我是不是不理解如何使用TDD和自动单元测试？