Thanks for the info on FuncUnit -- looking forward to it.
--
We made a proof-of-concept for tests which required the user to be logged in -- we initially did it by having the test fill out and submit the login form, but that got annoying fast (since we don't want to run through that fill-out-the-login-form stuff every time) and it seemed to push us towards writing huge, lengthy tests.
Here are three ideas we've come up with -- they all seem to work, but we haven't done anything beyond prototypes so far:
Difficulty-wise, none of these was too rough -- although making fixtures could take some time. So far, the hardest part is just coming up with a standard.
--
We made a proof-of-concept for tests which required the user to be logged in -- we initially did it by having the test fill out and submit the login form, but that got annoying fast (since we don't want to run through that fill-out-the-login-form stuff every time) and it seemed to push us towards writing huge, lengthy tests.
Here are three ideas we've come up with -- they all seem to work, but we haven't done anything beyond prototypes so far:
- Do a model operation manually when setting up the test. We have a method called "authenticate" on the model itself, which acts like the REST operations except it hits a login url. Then we just do MyAccountClass.authenticate({ login: "foo", password: "bar" }). This is what we're planning to use -- and, similarly, we're also planning to use "SomeClass.create(...)" for creating temporary resources for other tests to mess around with.
- In our app, if you visit a page when not authenticated then it redirects you to the login form. Because the funcunit test conditions wait for a particular page/dom state, we could set up each test to always wait for the desired page to render before beginning the tests -- which is a good practice anyway. Then, if the browser gets redirected to the login page, a user who's watching the screen can quickly type in the login/password: if they submit it quickly enough, the test won't even notice. I'm not fond of this approach, since it requires a user to be in front of the screen, but it lets you avoid hardcoding login/password into the tests themselves.
- Mock out each request in a fixture. We decided not to go this route because we want to test the actual backend -- instead of doing 'true' unit tests for canjs, our canjs tests are just going to be our end-to-end tests.
Difficulty-wise, none of these was too rough -- although making fixtures could take some time. So far, the hardest part is just coming up with a standard.