8

我喜欢Cucumber将用户规范与集成测试联系起来的方式。这Cucumber部分对我来说或多或少是清楚的。
当谈到应该用 rspec（非集成测试）测试什么和不应该测试什么时，我很挣扎。对已经测试过
的东西进行单元测试是否正确（例如，如果 Cucumber 测试失败，单元测试将 100% 失败，如果 Cucumber 测试成功，单元测试将 100% 成功）？rspecCucumber

具体来说，我想解决三个例子。

  1. 这是 RSpec 书中的一个案例。他们有以下几点Cucumber scenario：

    Given I am not yet playing
When I start a new game
Then I should see "Welcome to Codebreaker!"
And I should see "Enter guess:"

    他们在之后建造了两个rspec-tests：

    describe "#start" do
     it "sends a welcome message" do

     end
     it "prompts for the first guess" do

     end
end

  2. 另一个例子是测试路由或动作重定向，同时有以下场景：

    Given I am at the login page
When I fill in the right username and password
Then I should be at the index page

  3. 有时我们会测试已经测试过的助手Cucumber：

    Given Mike has spent 283 minutes online
When I go to the Mike's profile page
Then I should see "4:43" for "Time online:"

    我可能应该测试将 283 分钟分成“4:43”的助手，但事实证明它已经用Cucumber.

它可能不是最好的例子，但它说明了我在说什么。
对我来说，这些测试是重复的。

你能评论一下上面的例子吗？

是否有任何关于应该用什么进行测试的原则或指导rspec方针Cucumber tests？

4

1 回答 1

10

所有这些只是我对这个广泛而开放的话题的个人看法。有些人可能不同意，而且他们可以很有趣。

作为一般指南，您应该使用Cucumber来测试整个应用程序堆栈，这就是所谓的用户体验。此应用程序堆栈可能由许多较小的独立对象组成，但是，就像使用您的应用程序的用户不会对这些细节感兴趣一样，您的黄瓜测试不应该关心它们，而是关注应用程序的外层。

另一方面，RSpec（在您的设置中！ ）应该主要关注那些小对象，即应用程序的构建块。

书中的小应用示例存在一个大问题：它们太小了！

Boarder between outer layer of your application and its interiors is to blurred. Entire application is build with two objects! It is hard to distinguished what should test what. As your application grow in size its getting more obvious what is a user experience test(cucumber) and what is object - state test/message expectation test(RSpec).

Using your second example:

With this Cucumber story:

Given I am at the login page
When I fill in the right username and password
Then I should be at the index page

Rspec:

You will probably have some sort of User model:

  • test user name syntax(must start with capital for example)
  • test password must be 7 characters have numbers etc...

You can have some sort of authentication object:

  • test for valid and invalid logins etc
  • test for exceptions being thrown ....

What if your Authentication database is on different server?

  • mock connection and authentication database and test if database receive an request from authentication object.

And yada yada yada... Forever your cucumber test will guard general purpose of your application user login. Even when you add or change behaviour, under the hood, as long as this test pass you can be confident that user can login.

  • you should test things once(in one place)
  • object its responsible for testing its incoming massage(object public interface) for state(return value)
  • when your object depends on other object(sends its a message) don't test it for state(return value) that object is responsible for it.
  • when your object depends on other object(sends its a message) mock that second object and test if it receive your message.

Generally your question is too broad and you wont find a single answer, different people will have different ideas. What you should focus on is to test, as good as you can and with time you will definitely find right way for you. Not a great test suit is much better then none.

Because good design helps to write good test I would recommend Practical Object-Oriented Design in Ruby: An Agile Primer by Sandi Metz(which is one of a best book I've read)

于 2013-03-31T01:52:56.213 回答