Writing apps with today's rich client libraries such as Extjs , YUI , and JQuery really shows how much potential is still left in web development. But it takes a lot of code, and the amount of technical debt can get heavy, quickly. Good tests can help reduce this technical debt, and there are a lot of testing tools available for the client. Today though, I want to go beyond just using a tool, and talk more about integrating your JavaScript tests into an existing Continuous Integration environment.
I have a confession to make- I hate running tests manually. I'll write tests when I'm doing new development or bug fixing, but I hate running them after I've fixed the bug or implemented the code. That's why we have CI environments, right? So I don't have to run the stupid tests each time! There are enough ridiculous rules put in place in corporate work environments today already, I don't like adding tasks that can be automated into the mix.
Here's what I've come up with for integrating my JavaScript Unit Tests:
- Write tests with Screw.Unit . Why Screw.Unit? I like the simple DOM it creates. I like the code behind it- specifically the separation of builders and matchers. It's relatively easy to debug my code in Firebug. But mostly, it's because it's of the easy DOM it displays. There's nothing magical about Screw.Unit. It's just a simple tool. But that's the point.
- Use HtmlUnit to execute Screw.Unit tests, and inspect the results. HtmlUnit has the best JavaScript framework support in the Java world today. It uses Rhino to execute JavaScript and has written very comprehensive DOM support on top of that. It can handle most major JS framework code. So I execute my tests with HtmlUnit, and then inspect the simple DOM results. Easy!
- I use a Parameterized JunitTest to read through all of my ScrewUnit tests (*.html files), and execute a JUnit test for each.
Done! Simple integration at it's best.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
Post a Comment