ability to use html test runner files #66
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
It would be nice to have the option to use html files instead of yml files to define a suite.
The html file would be useful because it would allow you to use a browser's debugging tools. Another benefit would be that I wouldn't have to define both a yml and html test runner files.
How would you envision this working? The runner builds a lot of support JavaScript into the HTML pages it creates to make things work -- things like Jasmine itself, a custom reporter, information on the files being tested for reporting purposes, and object inspection code. What would you put into the HTML file you're providing to JHW so that you would be able to take advantage of all of this?
I guess there would need to be a JHW js file linked in the html page that would do this.
If it helps, here's some backstory. I started a project using jasmine-headless-webkit with it's coffeescript options. Then I encountered some bugs in my code that required deeper inspection. So I created my own HTML file for running the tests, and it used the coffeescript js to convert the compile the code over. Then that became problematic, because inspecting the dynamically generated js was a pain, so I abandoned coffeescript altogether.
Now I'm using straight javascript and developing/testing within the HTML test runner first because of the visibility I get from the debugging tools. After I get it to a point where I want to deal with it, I'll update the yml file and modify the code to work headlessly. This means that any markup that my tests depend upon has to be created with js.
So, I started out thinking I could get away with a quick headless TDD solution, but it turns out that the headless runner is more useful to check for regressions after I've done the development. And I have to modify the tests to run properly in it.
Right now, jasmine-headless-webkit is great for pure javascript unit tests, but it's a bit more involved when working with the DOM.
If I could point jasmine-headless-webkit at an html test runner, then it would alleviate these pains.
The better solution would be to use the generated HTML file from JHW in your browser, however that needs some work to make work nicely, since I have a custom reporter in there. It's impractical to find some way to "import" an arbitrary HTML file and have it all work cleanly -- there's too much room for error. I'll ponder the best way to export a file that a browser can use with no modifications (or feel free to dive into the code and experiment).
The second best solution is to improve the inspection capabilities of JHW. Are you using jQuery? Backbone.js? If you're using jQuery,
jasmine-jqueryis pretty much a requirement. The latest master HEAD has some huge improvements to introspection that aren't in a gem release yet. Do any of the changes in there make a difference? I improved the line number feedback for CoffeeScript files, though it's impossible to get those 100% accurate. The one thing that I know is missing is stack traces, but I've been unable to build a copy of QtWebKit with V8 or with some new patches that enable proper stack traces in JavaScriptCore. :(I now have a hankerin' to start messing with this. I have another use case that would need generated files that I want to start experimenting with. I'll play with it a bit this weekend/next week and see what I can get going.
Cool. If you're going to experiment with outputting an html file, I have a suggestion:
I would like to be able to specify the filename in the yml file.
In my particular project, I have several yml files to test various interface's scripts. So in one yml file, I would name the rendered html file
admin.html, and another may bemobile.html.I've started on this with this commit, which cleaned up a lot of infrastructure to make writing out report files easier and cleaner:
0be7b9e20cI'll work on the rest of it in the coming days.
OK you can now define a
runner_outputvalue in yourjasmine.ymlfile and get a copy of the runner wherever you specify. You can also override this from the command line with the--runner-outoption.Both of these output a browser-friendly runner, using Jasmine's
HtmlReporter. Try it and let me know what you think.Have you had a chance to try this out? If this is working for you, I'm going to end up doing a release today or tomorrow.
Awesome! No, I haven't had a chance yet. It'll probably be the end of the week before I can get to it. Don't wait on me to push out a new release :)
Regardless, I'll let you know how it works out.
Quick question: will the runner automatically pickup changes to the specs? Or you need to run it in the terminal to get a static runner?
Cheers,
@divoxx, the command line tool needs to be run in order to generate a new HTML file that contains your specs and Jasmine. Coupling with Guard makes that regeneration process a lot easier.
Cool, thanks for the quick answer ;)
This is working for me, I put it through its paces when testing app conversions to Sprockets, so I'm closing it. Reopen if there's still issues.
@johnbintz I gotta say that
runner_outputworks like a charm. Upgrading was easy, and this really is going to be useful. Thank you!