[LRUG] Fwd: Testing JS in Rails 4

[Will Tomlins]

I do see your point about "weird opaque and brittle glue libraries".  That aside, it seems to me that you're going to need at least something server-side to generate a source file list unless you just test the raw, uncompiled assets.  Personally I don't really see what's wrong with testing the raw assets directly in unit tests - surely to test that they still work after compiling is to test the compiler.  I'd say they want to be compiled for acceptance tests but I'm assuming acceptance testing isn't the problem here.



On 31 Jul 2013, at 16:29, James Coglan wrote:

> On 31 July 2013 16:07, Will Tomlins <will at tomlins.org.uk> wrote:
> Just a thought, but have you considered making use of node?  I've had some success unit testing using jasmine with grunt-contrib-jasmine (https://github.com/gruntjs/grunt-contrib-jasmine) but using PhantomJS as a test runtime.
> 
> Yes. Not those exact tools, but yes. I actually maintain my own test framework that runs on Node (and lots of other platforms), and my current concat/minify build tool is written in Node, mostly so I can use the Uglify scripting API to make it build working source maps.
> 
> I'm still of the opinion that JS test suites should consist only of static files, because of my experience trying to get test suites to run across a ton of different platforms. So relying on a server, be it Rails or Node, is out.
> 
> <rant> Stuff like grunt-contrib-jasmine is exactly what I was referring to with "weird opaque and brittle glue libraries". They always tend to couple one test framework very tightly to one target platform (in this case Jasmine to PhantomJS, and both of these to Grunt), mix in a bunch of unrelated concerns so so that you can't handle those concerns yourself (see all the options this lib supports) and don't expose their functionality in a generically useful way (such as hiding a ton of functionality behind an interface you can only use through Grunt). Given the combinatorial explosion of JS frameworks and runtimes, these tools make it hard to run your tests on a variety of platforms, encourage you to couple your tests to them, mask portability problems in the underlying tools with brittle glue, and fail as soon as you have a use case the author didn't think of, which happens a lot, at which point you need to disentangle your tests from the tool and migrate to some other thing. </rant>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130731/69e930d7/attachment.html>