没有一种方法可以决定是否编写一个无需思考即可使用的集成测试。 任何真实的应用程序都具有挑战任何规则的细微差别和特殊情况。但是肯定存在一种通用方法,除非你发现它不适用,否则你可以遵循这种方法:使用验收测试作为集成测试。
顺便说一下:我认为“集成测试”是指测试涵盖了代码的多个层面,而不是Rails特定意义上的定义,后者已经被更好的方法和工具所取代。但如果您确实使用Rails集成测试,我的答案也适用。
验收测试捕获重要的用户流程。它还是一种集成测试,从UI到后端,测试了应用程序的所有层面。行为驱动开发(BDD)等类似方法通过为所有重要的用户流程编写验收测试来推动从外部向内部的开发。验收测试编写复杂且运行速度较慢,因此尽量编写最少的测试以仍然定义所有重要的用户流程。
选择验收测试是一门艺术,但一个经验法则是,如果两个场景涉及不同的参与者和/或不同的主要系统组件(例如UI屏幕),则它们应该拥有单独的验收测试;否则,它们是具有细节的相同场景,一个验收测试就足够了。
验收测试对于与利益相关者(即记录需求)进行沟通非常有用,因此无论您的其余测试策略如何,都需要它们。但是,通常发现完整的验收测试集就是您所需的所有集成测试。不值得进行验收测试的详细要求可以在单元测试中表达。
在您的示例中,我可能会为用户创建自己的约会和父母帮助的场景编写一个验收测试,因为它们会非常不同。第一个可能是这样的(使用Gherkin)。
When I visit the new appointment page
And I create a new public appointment
And I visit my calendar
Then I see the public appointment
但第二个则会有所不同:
When there is an unrestricted user "Dad"
And there is a restricted user "Billy" supervised by "Dad"
And there is a user "Stalker"
When "Billy" visits the new appointment page
And "Billy" creates a new appointment
And "Billy" visits his calendar
Then "Billy" sees a pending appointment
When "Stalker" visits "Billy"'s calendar
Then "Stalker" does not see an appointment
When "Dad" visits "Billy"'s calendar
And "Dad" approves the pending appointment
Then "Dad" sees an appointment
When "Billy" visits his calendar
Then "Billy" sees an appointment
When "Stalker" visits "Billy"'s calendar
Then "Stalker" does not see an appointment
另一方面,如果位置只是一个可能填写或不填写的文本字段,我可能不会为具有位置和没有位置的情况编写两个不同的验收测试。在这种情况下,单元测试可能就足够了。