Writing acceptance tests is enough? Are controller/model/view tests necessary?

rubyonrails-talk
#1

I'm new in BDD, i'm writing now my first app in BDD way. I'm using
RSpec with Steak for acceptance tests ( https://github.com/cavalle/steak
).

I wrote first acceptance test for user signuping:

user clicks sign up link on homepage
fills all fields in sign up form
clicks submit button
checks for activation email

Should I test views here? Homepage to contain Sign up link with good
href and new user form for contain all fields and good action= and
method="post"?

Is views testing practiced in BDD at all? Or, are in BDD accteptance
tests enough and there is no need for model/controller/view tests?
Becouse if we test all the features, all behaviour which we want from
our app in acceptance tests, what for would be other tests? For
example, if we have scenario when user goes to homepage, clicks sign
up and signs up, there is no need to even write 'should be success'
for home controller and users controller, becouse we already test it
in that scenario. Similar with models - if signing up and validating
works well, there is no need for model tests.

What are you think about it? What are real-life practices of BDD?

#2

The general rule is: acceptance tests are for your customers, unit and
functional tests are for you.

Well-written acceptance tests prove that users can complete entire,
potentially-complicated interactions and see the right thing on the
screen. If you are developing for a customer or with a project
manager, acceptance tests should correspond to the requirements or
user stories, and if they all pass that should prove that you have
done your job.

Well-written unit tests prove that small pieces of your code are
modular and behave correctly. A customer is not interested in them, as
they likely specify behavior about which objects send which messages
to each other.

Why have unit tests if acceptance tests prove your application works?
Well, let's say something goes wrong in an acceptance test and the
user account can't be created. You now have a fun list of things to
check:

1. Maybe the test is just written wrong.

2. Maybe the html is just getting rendered wrong.

3. Maybe the controller just isn't sending the right redirect.

4. Maybe the model validations are failing?

5. Maybe the model internal logic isn't working?

6. Maybe the controller isn't getting the right params?

7. Maybe the form isn't displaying the fields correctly?

Unit tests should cover points 4&5, functional tests would cover 3&6.
When something goes wrong in the acceptance tests, you look at the
results from the unit and functional tests to tell you where it is
going wrong.

You also use unit and functional tests to prove the behavior of your
objects in order to change your code to be better but without breaking
anything.