Fewer but bigger acceptance tests

[rafamanzo]

Now that we have a solid acceptance test coverage and the features are stable, would be nice to minimize the repeated steps.

One way to do that is by writing big scenarios that tests many features.

[LarissaRodrigues]

Is this issue already done? I reviwed them and all I could do was create a background for similar test cases for a single feature, the tests themselves look pretty complete. Should I keep going this way?

[rafamanzo]

No. This issue is about refactoring the existing acceptance tests.

Now, prezento has lots of acceptance tests, basically one for each single feature and usage scenario.

The idea here is to rewrite the existing tests into bigger ones. Like testing the user creation, reading group creation, configuration creation, project creation, repository creation and processing results into a single and large acceptance test for example.

This will save us the time of creation of objects for other test cases and kalibro resets.

The example above is just an exaggerated example. Don't take it too seriously :)

[LarissaRodrigues]

I wonder if the issue relates to what I am doing at the link below:
LarissaRodrigues@6460629

I am reducing the number of scenarios, making scenarios with similar steps
into one.

=)

2014-12-04 14:14 GMT-02:00 Rafael Reggiani Manzo [email protected]:

No. This issue is about refactoring the existing acceptance tests.

Now, prezento has lots of acceptance tests, basically one for each single
feature and usage scenario.

The idea here is to rewrite the existing tests into bigger ones. Like
testing the user creation, reading group creation, configuration creation,
project creation, repository creation and processing results into a single
and large acceptance test for example.

This will save us the time of creation of objects for other test cases and
kalibro resets.

The example above is just an exaggerated example. Don't take it too
seriously :)

—
Reply to this email directly or view it on GitHub
#24 (comment).

Larissa Rodrigues.

[rafamanzo]

Yes that's the spirit!

[rafamanzo]

#262 has taken the place from #168

By running cucumber -f usage we get the steps in order of the slowest and information about unused steps. This is useful to find out which features are worthy to get merged first.

[rafamanzo]

Furthermore we should rethink our acceptance tests in the way that some behaviour can be tested on the unit level.

For example, acceptance tests that check just for UI features can be extracted into view specs (https://www.relishapp.com/rspec/rspec-rails/v/3-0/docs/view-specs/view-spec).

[rafamanzo]

b5b20a6 merged two scenarios into one.