TheProjecter / phantomjs-qunit-runner

Automatically exported from code.google.com/p/phantomjs-qunit-runner
0 stars 0 forks source link

Support typical maven wildcards, or support multiple entries for js and test folders #6

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
My javascript is sorted in multiple folders. I like this arrangement and don't 
want to change it.

I would love to use this plugin if it could handle one of these approaches:

{{{
...
<configuration>
  <jsSrcDirs>
    <jsSrcDir>src/main/webapp/common</jsSrcDir>
    <jsSrcDir>src/main/webapp/components</jsSrcDir>
    <jsSrcDir>src/main/webapp/site</jsSrcDir>
  </jsSrcDirs>
  ...(mirrored for test)
</configuration>
}}}

or...

{{{
<configuration>
  <jsSrcDir>src/main/webapp/**/*.js</jsSrcDir>
  <jsTestDir>src/test/webapp/**/*Test.js</jsTestDir>
</configuration
}}}

How cool would that be? Awesome, I say!

Original issue reported on code.google.com by NashvilE...@gmail.com on 23 Feb 2012 at 9:57

GoogleCodeExporter commented 8 years ago
My vote goes for option 2, using globs to define recursive paths.  Something 
like this:
<jsSrcDirectory>src/main/js/**/</jsSrcDirectory>
or this:
<jsSrcDirectory>src/main/js/{,**/}</jsSrcDirectory>
or this:
<jsSrcDirectory>src/main/js/**/*.js</jsSrcDirectory>
Should work (the last one being a file search, the first two being directory 
searches).  Any of those would be useful, and all should work with a change to 
use a pattern search on the folders.

Original comment by br...@newtonius.com on 17 May 2012 at 7:26

GoogleCodeExporter commented 8 years ago
After looking through the code, it seems easier to just recursively list files 
in the directory provided.  So if:
<jsSrcDirectory>src/main/js/</jsSrcDirectory>
It should find all js files in that directory recursively.

Original comment by br...@newtonius.com on 18 May 2012 at 1:00

GoogleCodeExporter commented 8 years ago
Hi Brian,
This functionality is key for the project my company is working on as we have 
our javascript code split into many different directories. When could we expect 
this fix and what version of phantom js would this be?

Regards,
Nick

Original comment by narent....@gmail.com on 25 May 2012 at 8:27

GoogleCodeExporter commented 8 years ago
@Nick:

Looks like this feature request probably isn't getting in.
What I did instead might work for you, too.

This will sound a bit complicated because of all the moving parts, but each 
part is simple, so bear with me.

Steps to automate qunit test running:

1 - Create a qunit run page in .jsp. Call it maybe 'runAllTests.jsp'. This page 
should run all the qunit tests traditionally when you visit it in a browser. I 
used some simple loops and other jsp filesystem stuff to scan the directories I 
wanted for .test.js files. This gets all the tests you want run whenever you 
visit this page, but doesn't give you any automation. That's next.

2 - Create a JS file for phantom that will load your runAllTest.jsp page, log 
results to the console, and exit with 1 or 0 based on success or failure. You 
can also have this JS file build you JUnit compatible XML. The whole thing is 
about a page and a half of code. You can look at this as a starting point: 
https://gist.github.com/796548. You need to exit 1 or 0 so that later when 
maven runs this it knows whether to fail or pass the build.

3 - Now create a .sh or .bat file, or both, that will tell phantomjs to run the 
js file you created in step 2.

4 - Now use the maven exec plugin to run your .sh or .bat file. I use machine 
specific properties (set manually, unfortunately) to decide between .sh and 
.bat.

That's the whole thing. So in the end, the maven exec plugin runs your .sh 
file, which tells phantomjs to trigger this JS test runner file that you 
created, which loads and records results for the runAllTests.jsp page you made.

Good luck :)

Original comment by NashvilE...@gmail.com on 27 May 2012 at 2:38

GoogleCodeExporter commented 8 years ago
I'm trying to contact the author to be able to contribute to this project.  I 
also hope to work on getting this done in the next couple of weeks.  I just 
attached a new javascript runner file on issue 1 that should help give better 
output.  I'm going to start on making the java part recurse source directories 
now.

Original comment by br...@newtonius.com on 28 May 2012 at 9:44

GoogleCodeExporter commented 8 years ago
Any news on this issue yet? I un-intentionally created a duplicate issue (#11). 
I made it recurse the test directories and run all tests found. It also 
displays a decent log message regarding the test results. I'm not sure whether 
this enhancement will be included in the next release or not, but I feel the 
need to modify this plugin to make it fit my project's needs.

Original comment by rrnata...@gmail.com on 9 Oct 2012 at 6:26

GoogleCodeExporter commented 8 years ago
Wanted to use this plugin but this issue is holding us back, the fix in issue 
11 seems like it could do the trick, no chance of merging that in? 

... or is this project dead?

Original comment by adamjjes...@gmail.com on 31 Oct 2013 at 12:27

GoogleCodeExporter commented 8 years ago
I don't know the status of this plugin, but it hasn't been active for quite 
some time.

I can tell you that we've decided to start using gruntjs to do our unit testing 
and we are going to remove this plugin from our pom.  You can have maven run 
gruntjs (see this post by Addy Osmani 
http://addyosmani.com/blog/making-maven-grunt/).  We've opted to make it a 
build step that's executed before maven runs.  We're putting our js and css 
code in src/build, and then grunt does the unit testing, linting, sass 
compilation, or whatever you want done first and puts the results in src/main.  
If grunt passes, then we run maven.  The thing we like about this approach is 
that you don't have to do a full build just to see if one of your unit tests 
failed, or if you forgot to put a === instead of ==, failing jslint.

At any rate, gruntjs will give you a METRIC TON of plugins to do whatever you 
want to do to your files before maven gets a hold of them.

Oh, lastly, we're going to use a pre-commit hook in git to run grunt locally 
before committing, which will help us catch problems before we're even allowed 
to commit them.

Original comment by br...@newtonius.com on 31 Oct 2013 at 2:01