first unit test and integration test

A quick test that the homepage works and that the login succeeds in three cases (failure, unconfirmed, and success).
On Thu, Jun 26, 2014 at 07:41:14AM -0700, Brian Grayless wrote:
> It seems like if there was a concern about a test not working that either the tests can be abstracted and/or simplified, or that maybe an additional test like this one would just use the same kind of logic but to test a different scenario, rather than use capybara form submittal for one, and the a post for the other.

The goal here was really to make sure the capybara test was correct... can't really test capybara with capybara.

Consider the following though with my last comment on labels too: suppose we change a label among a few other things and a test fails.

If the only one is the 'login successfully', all we know that broke is that the login now doesn't work. But why? Is the login logic broken? The user model? The form? The little E rails puts out doesn't tell.

But if each piece is tested independently then it becomes pretty clear: a unit test on the user model ensures that is sane. (Since that's done by devise i'm assuming they do that for us; this would be a bug in the gem rather than our code).

The plain post test then checks the *controller* - did the path and programmatic fields actually work? If that fails, we know there's a controller problem independent of the view.

Then capybara polishes the whole thing off by testing the view and controller together, making sure they are still in sync. If the plain one succeeds and capybara fails, we know the problem is in the view. If both fail, we can focus on the controller.