Skip to content
This repository has been archived by the owner on Jan 29, 2019. It is now read-only.

Add automated JavaScript testing #151

Open
Osmose opened this issue Apr 12, 2013 · 4 comments
Open

Add automated JavaScript testing #151

Osmose opened this issue Apr 12, 2013 · 4 comments

Comments

@Osmose
Copy link
Contributor

Osmose commented Apr 12, 2013

We really really really need some form of automated testing for the JavaScript. Since we'd like to have them run on TravisCI as well as locally, our options are a little limited.

I made a bit of progress on this a while ago using CasperJS, you can see my progress on my casperjs-tests branch. However, I'm not sure if CasperJS can handle the Persona popup.

@willkg
Copy link
Member

willkg commented Apr 12, 2013

By "casper-js branch", I think you mean this commit: Osmose@dcdc1de

Figured it makes it easier to have the explicit link.

@Osmose
Copy link
Contributor Author

Osmose commented Apr 12, 2013

There were two asdf commits and I thought that they were both CasperJS stuff, turns out one was just in-progress work of an unrelated branch. Doh!

Also I know that there's stuff missing from that commit. I had to do some jumping to get the right packages and such installed. Helpful links I remember using include:

Osmose pushed a commit to Osmose/django-browserid that referenced this issue Dec 12, 2013
Extracts the API from browserid.js and moves it to a new file, api.js,
that authors can include on their own if they don't want the automatic
behavior of browserid.js. This also allows us to unit-test the API 
while ignoring the onload stuff from browserid.js.

There aren't tests yet for browserid.js as that would better be handled
by end-to-end tests using something like Selenium.
Osmose pushed a commit to Osmose/django-browserid that referenced this issue Feb 18, 2014
Extracts the API from browserid.js and moves it to a new file, api.js,
that authors can include on their own if they don't want the automatic
behavior of browserid.js. This also allows us to unit-test the API 
while ignoring the onload stuff from browserid.js.

There aren't tests yet for browserid.js as that would better be handled
by end-to-end tests using something like Selenium.
@Osmose
Copy link
Contributor Author

Osmose commented Feb 18, 2014

b4b772f adds unit testing for the JS API, which is really handy. We still don't have testing for the JS that actually binds clicks on the buttons to those functions, but that is less unit-testy and more end-to-end-testy, especially in multiple browsers.

I don't think that particular part is going to block the next release, but perhaps it's worth it as a 1.0 goal?

@willkg
Copy link
Member

willkg commented Feb 18, 2014

I think as long as the number of important pieces being tested is monotonically increasing, i don't have a preference for which version which tests make it into.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants