当应用程序为 100% CRUD 时应用 TDD [英] Applying TDD when the application is 100% CRUD

问题描述

我经常遇到这个问题，我不知道如何克服这个障碍.我真的很想开始学习和应用测试驱动开发(或 BDD，或其他)，但似乎我想要应用的每个应用程序几乎都只是标准数据库 CRUD 的东西，我不确定如何去应用它.这些对象除了被持久化到数据库之外几乎不做任何事情；没有需要测试的复杂逻辑.有一个网关，我最终需要测试第 3 方服务，但我想先完成应用程序的核心.

I routinely run into this problem, and I'm not sure how to get past this hurdle. I really want to start learning and applying Test-Driven-Development (or BDD, or whatever) but it seems like every application I do where I want to apply is it pretty much only standard database CRUD stuff, and I'm not sure how to go about applying it. The objects pretty much don't do anything apart from being persisted to a database; there is no complex logic that needs to be tested. There is a gateway that I'll eventually need to test for a 3rd-party service, but I want to get the core of the app done first.

每当我尝试编写测试时，我最终只会测试我可能不应该首先测试的基本内容(例如 getter/setter)，但看起来对象没有其他任何东西.我想我可以测试持久性，但这对我来说似乎永远不正确，因为你不应该实际访问数据库，但是如果你模拟它，那么你真的没有测试任何东西，因为你控制了回吐的数据；就像我看过很多例子，其中有一个模拟存储库通过循环和创建已知值列表来模拟数据库，并且测试验证存储库"可以拉回某个值......我没有看到这样的测试点，因为存储库"当然会返回该值；它在课堂上是硬编码的！好吧，我从纯 TDD 的角度来看它(即，您需要进行一个测试，说明您的存储库需要一个 GetCustomerByName 方法或其他方法，然后才能编写该方法本身)，但这似乎无缘无故地遵循教条，除了它的方法" - 除了证明方法的合理性之外，测试似乎没有做任何有用的事情.

Whenever I try to write tests, I only end up testing basic stuff that I probably shouldn't be testing in the first place (e.g. getters/setters) but it doesn't look like the objects have anything else. I guess I could test persistence but this never seems right to me because you aren't supposed to actually hit a database, but if you mock it out then you really aren't testing anything because you control the data that's spit back; like I've seen a lot of examples where there is a mock repository that simulates a database by looping and creating a list of known values, and the test verifies that the "repository" can pull back a certain value... I'm not seeing the point of a test like this because of course the "repository" is going to return that value; it's hard-coded in the class! Well, I see it from a pure TDD standpoint (i.e. you need to have a test saying that your repository needs a GetCustomerByName method or whatever before you can write the method itself), but that seems like following dogma for no reason other than its "the way" - the test doesn't seem to be doing anything useful apart from justifying a method.

我是不是想错了?

以运行工厂联系人管理应用程序为例.我们有联系人，假设我们可以向联系人发送消息.因此，我们有两个实体:Contact 和 Message，每个实体都有共同的属性(例如名字、姓氏、联系人的电子邮件以及消息的主题和正文和日期).如果这些对象都没有任何实际行为或需要执行任何逻辑，那么在设计这样的应用程序时如何应用 TDD?该应用程序的唯一目的基本上是拉取联系人列表并将其显示在页面上，显示表单以发送消息等.我在这里没有看到任何有用的测试 - 我可以想到一些测试，但它们几乎是为了说看，我有测试！"的测试.而不是实际测试某种逻辑(虽然 Ruby on Rails 很好地利用了它，但我并不真正认为测试验证是有用的"测试，因为它应该是框架为您处理的事情)

For example take a run of the mill contact management application. We have contacts, and let's say that we can send messages to contacts. We therefore have two entities: Contact and Message, each with common properties (e.g. First Name, Last Name, Email for Contact, and Subject and Body and Date for Message). If neither of these objects have any real behavior or need to perform any logic, then how do you apply TDD when designing an app like this? The only purpose of the app is basically to pull a list of contacts and display them on a page, display a form to send a message, and the like. I'm not seeing any sort of useful tests here - I could think of some tests but they would pretty much be tests for the sake of saying "See, I have tests!" instead of actually testing some kind of logic (While Ruby on Rails makes good use of it, I don't really consider testing validation to be a "useful" test because it should be something the framework takes care of for you)

推荐答案

该应用的唯一目的，基本上就是拉取联系人列表"

"The only purpose of the app is basically to pull a list of contacts"

好的.测试一下.拉"是什么意思?这听起来像是逻辑".

Okay. Test that. What does "pull" mean? That sounds like "logic".

在页面上显示它们"

好的.测试一下.正确的显示?一切都在那里?

Okay. Test that. Right ones displayed? Everything there?

"显示发送消息的表单，"

" display a form to send a message,"

好的.测试一下.正确的领域?输入的验证都有效吗?

Okay. Test that. Right fields? Validations of inputs all work?

"等."

好的.测试一下.查询有效吗?找到正确的数据?显示正确的数据?验证输入?为无效输入生成正确的错误消息?

Okay. Test that. Do the queries work? Find the right data? Display the right data? Validate the inputs? Produce the right error messages for the invalid inputs?

这篇关于当应用程序为 100% CRUD 时应用 TDD的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！