> Moreover, JS is really fast to write and test. Write – save – refresh; it’s an absurdly fast dev cycle that lets me iterate on questionable portions of the code much faster than any environment I’ve worked in.
I'm planning on looking into headless testing to eliminate the whole icky business of switching to the browser and hitting refresh. I find this much more of a drag than rerunning server side tests in a terminal.
Almost impossible to setup non-headless with Continuous Integration. Any solution with that?
By the way, I used to work using GWT and the way we test it is via using MVP pattern + JUnit for any logic code. Works well 99% minus the cross-browser UI bug (but then if we started testing the actual UI code then we're testing GWT itself).
A CI system just needs to be able to ingest the test results (usually as junit xml formatted text). You can easily do with with jsTestDriver or Selenium as your bridge from the running browser instances to the CI server.
I'm currently using Bamboo (Atlassian) running in AWS. Everything is done in AWS.
Let me try to digest and understand what you're saying:
- CI system can be made to work with jsTestDriver/Selenium as long as _somehow_ there is an input file to the build system (i.e.: JUnit XML formatted text).
That's true.
My next question is: I'd like to run everything (the unit-tests) in the same machine _without_ having to deploy and run the back-end as well. I'd like to mock the back-end communication with the UI so I can write unit-tests. Is there a way to do that with the current available JS test framework?
My next question is: if I'm running all of my CI in AWS, without an extra machine _with_ a monitor attach to it, can I still run jsTestDriver/Selenium?
I'm planning on looking into headless testing to eliminate the whole icky business of switching to the browser and hitting refresh. I find this much more of a drag than rerunning server side tests in a terminal.