If everyone else is in agreement I'd like to start instituting some policies with our javascript code similar to what we do with Java.
-) Now that we have a unit testing infrastructure in place for js it would be nice if all logic that is possible to be tested was. Obviously there is a lot of code sitting in there that didn't have the luxury of a unit test environment, but any new code / refactoring of js should include complimentary unit tests. -) When possible, it should probably generally be considered ~better~ to have a common generic function sitting in a .js file rather than creating whole function() blocks in our .script included files. This will reduce response size on requests as well as make the code easier to test. -) Until we can create our own guide or some other similar construct it would be a good idea to try and follow http://dojotoolkit.org/docs/js_style_guide.html for our script code to give it a uniform style. (I still need to re-read this guide myself :) ) I've picked up a few tricks / styling habits on some other projects that should hopefully also serve as a good reference as I start to add more / refactor existing code. The unit tests can't handle ~everything~ currently, but can still do a lot. It wouldn't be very hard at all to add a sort of "Mock" object capability in there if we need it. I'll probably be playing with this a lot more over the coming weeks. The ant jar I threw in there also uses mozilla rhino apis directly, so if we need more functionality in the runtime of our unit tests to make things easier it's possible to do. (so long as we don't go ~too~ far with it...don't want to try implementing a headless browser or anything) Of course I would love to see a set of selenium tests incporated as well, similar to what Andy started for tacos. Hopefully the TimeTracker app can be our integration test for this? -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
