Open ELLIOTTCABLE opened 9 years ago
You're completely right. That's why we are currently working mainly on splitting the project into separate packages for grunt, karma, mocha, and javascript mutations. That does not only remove the restriction for using grunt, but also makes it a lot easier to add other runners and test runners, and makes the whole project more maintainable.
The only reason why the project is currently so tightly tied to grunt is that it started out way smaller and it was initially uncertain whether it would work at all.
I unfortunately cannot make any promises on when it will be done, but at least we're working on it.
That's good news! Leave this open, and close it when you've got some early work ready for testing on the pure-JavaScript side? (=
Exactly what I was planning to do, again =)
Do you have a work in progress repo for it?
We haven't really had much time to work on it lately, as it's been quite busy at work and due to vacations. For now, Martin has extracted the JavaScript mutation testing part in https://github.com/paysdoc/js-mutation-testing, but this is a very early work in progress. No runners are available for it yet, and we might go for a slightly different approach in the mean time (just splitting the project first, and only then rewriting the mutation part).
Good news, all of that!
If there's work that needs to be done, something nicely-segregated that it may be easy for an outsider to tackle, but that would be time-consuming for you; let me know. I have a small amount of time on my hands, and this is a topic that's important to me. =)
You're welcome to contribute to js-mutation-testing. Basically I've written a bunch of mutation operators that apply the mutations to the AST (abstract syntax tree) node directly. An analyser traverses the AST and defines sets of mutation operators for each node in the tree. You end up with a list of mutation operator sets (I've chosen for mutation sets, because at a later stage I want to be able apply compound mutations, a.k.a. Higher order mutations). The MutationTester then iterates through that list, applies each mutation in each set and runs the given unit test.
That's roughly as far as I've got. I'm now busy writing unit tests to check that each component does what it should. Then I'll wire it all together, add configuration support and write some e2e tests.
After that I'll create a branch in this project that'll use the js-mutation-testing component.
So if you're keen to help with the unit tests, I'd be very grateful. Just fork js-mutation-testing and send soem PR's. Now that I'm back from holidays I tend to work on that project in the train twice a day, so I should be able to integrate your work regularly.
PS: I've made a class diagram for a bit of an overview: http://www.gliffy.com/go/publish/8133337
Could not the useful functionality of this codebase be extracted into something not depending upon using Grunt, and then a Grunt-runner for that extracted toolkit be written?
Not every project uses Grunt. And most that don't, don't wish to add an additional task-runner framework to their existing meta-project dead-weight. :P
Is there a particular rationale that I'm not seeing for this to be tightly tied to Grunt?