当应用程序是100％CRUD时应用TDD
我经常遇到这个问题，我不知道如何克服这个障碍。 我真的想开始学习和应用testing驱动开发（或BDD，或其他），但似乎每个应用程序，我做我想申请的是几乎只有标准的数据库CRUD的东西，我不知道如何去应用它。 除了被保存到数据库之外，对象几乎不做任何事情。 没有复杂的逻辑需要testing。 有一个网关，我最终需要testing第三方服务，但我想先让应用程序的核心。
每当我尝试编写testing时，我最终只能testing基本的东西，我可能不应该在第一时间testing（例如getters / setters），但看起来不像对象有其他东西。 我想我可以testing持久性，但是这对我来说似乎是不合适的，因为你不应该实际打到一个数据库，但是如果你嘲笑它，那么你真的没有testing任何东西，因为你控制了吐出的数据。 就像我见过很多的例子，有一个模拟库通过循环和创build一个已知值的列表模拟数据库，testingvalidation“存储库”可以拉回一定的价值…我是没有看到像这样的testing点，因为当然“知识库”将返回该值; 它在课堂上是硬编码的！ 那么我从纯TDD的angular度来看它（也就是说，在你写这个方法本身之前，你需要做一个testing，说你的版本库需要一个GetCustomerByName方法或者其他什么东西），但是这看起来好像跟随教条，除了它的“的方式“ – testing似乎没有做任何有用的东西除了certificate一个方法。
我在想这个错误的方法吗？
例如，运行一个工厂联系人pipe理应用程序。 我们有联系人，假设我们可以发送消息给联系人。 因此，我们有两个实体： Contact和Message ，每个实体具有共同的属性（例如名字，姓氏，联系人电子邮件以及主题和正文以及消息date）。 如果这些对象都没有任何真实的行为或需要执行任何逻辑，那么在devise这样的应用程序时如何应用TDD呢？ 应用程序的唯一目的是拉取联系人列表并在页面上显示它们，显示发送消息的表单等。 我在这里没有看到任何有用的testing – 我可以考虑一些testing，但是为了说“看，我有testing！”，它们几乎是testing。 而不是实际testing某种逻辑（虽然Ruby on Rails可以很好地利用它，但我并不认为testingvalidation是一个“有用的”testing，因为它应该是框架为您处理的）
“该应用程序的唯一目的是基本上拉一个联系人列表”
好的。 testing一下。 “拉”是什么意思？ 这听起来像“逻辑”。
“在页面上显示”
好的。 testing一下。 显示正确的？ 那里的一切？
“显示表单发送消息”
好的。 testing一下。 正确的领域？ 所有input的validation工作？
“等等。”
好的。 testing一下。 查询的工作？ find正确的数据？ 显示正确的数据？ validationinput？ 为无效input生成正确的错误消息？
我现在正在研究一个纯粹的CRUD应用程序但是我发现unit testing用例有许多好处（注意 – 我没有说TDD）
我先编写代码， 然后再编写testing用例 – 但是从来没有分开过，不过很快就够了
我也testingCRUD操作 – 对数据库的持久性。
当我完成了这个持久化过程并转到UI层时，我将对我的服务持久层有很好的信心，于是我可以在那个时候专注于UI。
所以恕我直言，总是有TDD \unit testing（不pipe你怎么称呼它取决于你对此感觉如何）的好处 – 甚至对于CRUD应用程序你只需要find适合你的应用程序的策略
只是使用常识….你会没事的。
我觉得我们把TDD和unit testing搞混了。
unit testing是testing行为单元的具体testing。 这些testing通常包含在集成构build中。 S.Lott为这些types的testing描述了一些优秀的候选人。
TDD是用于devise的。 我经常发现，当使用TDD时，我写的testing将被丢弃或演变成unit testing。 背后的原因是当我正在做TDD的时候我正在testing我的devise，而我正在devise我的应用程序，类，方法，域等…
为了回应您的情况，我同意S.Lott暗示的是，您所需要的是一套unit testing，以testing应用程序中的特定行为。
跳过它。 一切都会好起来的。 我相信你有最后期限见面。 （/讽刺）
下个月，我们可以根据用户反馈返回并优化查询。 打破我们不知道我们不应该打破的事情。
如果您认为该项目将持续2周，而不会重新开放，自动化testing可能是浪费时间。 否则，如果你拥有“拥有”这个代码几个月的既得利益，而且它的活跃，build立一些testing。 根据你的判断来判断风险最大的地方。 更糟糕的是，如果你计划和公司在一起几年，并且让其他队友轮stream在系统的各个部分上进行重击，并且可能会在一年之后再次轮到你，那就build立一些testing。
不要这样做，而是要“插几针”，这样，如果事情开始“走动”，就会有一些警报引起人们的注意。
我的testing大部分是JUnit或批处理“差异”types的testing，以及几年前我写的一个简单的屏幕刮板types工具（编写一些正则expression式+ wget / curltypes的东西）。 我听说Selenium应该是Web应用程序UItesting的好工具，但还没有尝试过。 任何人有本地GUI应用程序的可用工具？
TDD一个简单的CRUD应用程序在我看来就像在吉他上练习音阶 – 你可能会认为只有发现你的演奏提高了多less才是无聊和乏味的。 在开发方面 – 你可能会编写代码不那么耦合 – 更可testing。 另外，从代码使用者的angular度来看，您更有可能看到一些东西 – 您将会真正使用它。 这可以有很多有趣的副作用，比如更直观的API，更好的隔离问题等。当然，有脚手架生成器可以为你做基本的CRUD，他们确实有一个地方，特别是原型，但是他们通常绑定到一个框架各种各样的。 为什么不首先关注核心领域，推迟框架/用户界面/数据库决策，直到您对所需的核心function有更好的了解–TDD可以帮助您做到这一点。 在你的例子中：你想要消息是一个队列或分层树等？ 你想要他们实时加载？ sorting/search呢？ 你需要支持JSON或只是HTML？ 使用BDD / TDD查看这些问题要容易得多。 如果你正在做TDD，你甚至可以在不使用框架的情况下testing你的核心逻辑（等待一分钟来加载/运行）
只是一个想法…
按照CRUD的要求，使用watij或watir或AutoIt等工具来创buildtesting用例。 开始创buildUI来传递testing用例。 一旦你有了UI，通过一次testing，就可以开始为这个testing编写逻辑层，然后开始编写db层。
对于大多数用户来说，UI就是系统。 请记住为每个正在构build的新图层编写testing用例。 所以，而不是从数据库开始应用程序到UI层，开始在相反的方向。
在一天结束的时候，你可能会积累一套强大的回归testing集，给你一些安全重构的信心。
这只是一个想法…
我看到你在说什么，但是最终你的模型会变得足够先进，以至于他们需要（或者大大增强）自动化testing。 如果没有，你实质上正在开发一个电子表格，有人已经为你开发了。
既然你提到了Rails，那么对于每个属性来说，做一个标准的create / read / update / deletetesting是一个好主意，特别是因为你的testing应该注意到权限（这是我认为的巨大）。 这也确保您的迁移按照您的预期工作。
我正在研究一个CRUD应用程序。 我现在正在做的是在我的Repository对象上编写unit testing，并testingCRUDfunction是否正常工作。 我发现，这本质上也是unit testing了实际的数据库代码。 我们通过这种方式在数据库代码中发现了很多错误。 所以我build议你继续前进，继续进行unit testing。 我知道在CRUD应用上使用TDD并不像您在博客或杂志上可以看到的那样富有魅力，但是它在服务于您的目的，而您在处理更复杂的应用程序时会更好。
现在，除了UI之外，您不需要为CRUD应用程序编写大量手写代码，因为有101个框架将生成数据库和数据访问代码。
所以我会考虑减less手写代码的数量，并自动化UI的testing。 然后，我将使用需要手写的奇数位逻辑的TDD。
