buster.js support

[GoogleCodeExporter]

See http://blog.knuthaugen.no/2012/09/headless-tests-with-buster-and-phantom/ 
for one approach of running buster.js tests. It runs either in node.js mode or 
browser mode: http://docs.busterjs.org/en/latest/getting-started/#browser-tests

Original issue reported on code.google.com by cow...@bbs.darktech.org on 29 Nov 2013 at 4:01

[GoogleCodeExporter]

Could you describe better what are the requirements and acceptance criteria?

Thanks.

Original comment by alex.obj...@gmail.com on 29 Nov 2013 at 4:06

[GoogleCodeExporter]

I expect wro4j to launch buster.js and PhantomJS, run unit tests, shut down 
PhantomJS, and fail the build if any of the tests build. "It would be nice" if 
we could feed the exported JUnit results (as mentioned by the article) back 
into Maven but this is optional.

Original comment by cow...@bbs.darktech.org on 29 Nov 2013 at 4:10

[GoogleCodeExporter]

There are few things that worth to be discussed, like:

- how an unit test resource is identified? 
- how the resources to be tested are identified?

The "processor" can be described simply as a "function" which transforms the 
resource content from X (original) to Y (transformed). I'm not yet sure, how 
this simplistic processor definition can be mapped into the 
BuxterJsProcessor... 

Original comment by alex.obj...@gmail.com on 29 Nov 2013 at 4:19

[GoogleCodeExporter]

I don't understand the difference between "unit test resource" and "resources 
to be tested" means in your question. Please clarify.

I am expecting BusterJsProcess to take a single (optional) "config" argument. 
If specified, it should add "--config <value>" to the command-line when 
launching buster, otherwise buster will look for its configuration file at 
test/buster.js or spec/buster.js by default.

Original comment by cow...@bbs.darktech.org on 29 Nov 2013 at 4:23

[GoogleCodeExporter]

I must admit that I don't have much experience with js unit testing. But, to 
compare with java: 

the "unit test resource" - is the class located in src/test/java/ which 
contains unit test code. 
the "tested resource" - is a java class, usually located in src/main/java.

Similarly, comparing to the wro4j build configuration, given the WroModel 
(wro.xml), how do you know which resource from the model is a "test resource" 
and which one is the "tested one". Maybe the BusterJsProcessor doesn't make 
sense to be used in context of a WroModel...(?)...

If that doesn't make sense for BusterJsProcessor, please ignore my question 
:)... probably I need to read more about it. 

Providing as much details about the way the processor would be used, would be 
very helpful. Your previous comment is a good starting point, since it already 
describes an use-case. Diving into more details, would help to identify other 
potential use-cases.

Original comment by alex.obj...@gmail.com on 29 Nov 2013 at 4:31

[GoogleCodeExporter]

Ah! Okay.

Buster's configuration file is defined here: 
http://docs.busterjs.org/en/latest/getting-started/#create-config-file

"sources" refers to the "tested resource" and "tests" to the "unit test 
resource".

Original comment by cow...@bbs.darktech.org on 29 Nov 2013 at 4:36

[GoogleCodeExporter]

So, it would be completely decoupled from the resources defined in wro.xml.
It would require using a totally different convention regarding test resources 
description.

Original comment by alex.obj...@gmail.com on 29 Nov 2013 at 4:37

[GoogleCodeExporter]

I just found an alternative: 
http://docs.busterjs.org/en/latest/browser-testing/#using-an-html-scaffold

In short, you could generate an HTML file that loads the source files, followed 
by the test files. This causes the browser to execute the tests.

They provide more approaches on that same page (and demos at the bottom of the 
page).

I think that in general Buster favors running from node.js but it is my 
understanding that wro4j is not portable when using node.js so I'm trying to 
point you to browser execution. I think we'll be able to get this working 
without node.

Original comment by cow...@bbs.darktech.org on 29 Nov 2013 at 4:56