Integration Tests

[austinczarnecki]

#2015-03-02

Here are things we should have tests for:

• creating a reservation
  • as a patron
  • as a checkout person
• checking out equipment
• reservation actions
  • renewing a reservation
• checking in equipment
• admin actions?
• Active Admin (working routes)

---

Original

Start making some integration tests, probably most important to do this for the process of making a reservation.

[shippy]

Putting this in 3.3.0 milestone. We should probably create five to ten integration tests for the most common scenarios that we have in our user documentation?

[squidgetx]

If we really change up how the reservation workflow goes (via #523) we should either hold off on these tests or do like the real TDDrs do and write these tests with that new workflow in mind

[squidgetx]

Important Workflows

• Reservation making process
  • By users
  • By checkout people (for other users)
• Checking out equipment
• Checking in equipment

[squidgetx]

Conclusions after trying for a few hours to set up an integration test: this stuff is not for CAS. Controller stubbing is strongly discouraged in feature/request/integration testing and I wasn't able to bypass the current_user method in application controller to get to the meat of the app.

The only way this could go forward is if we had access to a dummy CAS account. The dev would have to log into this account manually in the browser and then run the test (which creates a user with the same netID).

I'm moving this out of 3.3.0 but I'm not closing, as this information may be useful in the future and/or if anyone every figures out how to deal with this.