Wallaby.js – An intelligent test runner that continuously runs your tests
wallabyjs.com
wallabyjs.com
Once more information is available I'll probably be interested.
So I try, and I like and I get used to it and then they start with "Oh you wanted to use that one really useful feature, That will be $5000 extra. Oh, you're running on Solaris, that will be $10000 extra. Oh you have more than 2 CPUs, that will be $20000 extra. Oh you want to use it Thursdays as well, that will be $30000 extra".
So now I never ever try software until I've seen a complete price list.
Wallaby.js will be less expensive than some similar commercial solutions for other languages.
In any case, feel free to sign up and to receive the pricing info as soon as it's available.
There's very little done for code analyze in JS, I can't even find an editor that gives me function parameter hints And show me a list of functions. I have even considered making my own editor.
Coding without such tools force me to write code that is easy to manage and review though.
I write a lot of tests and I've tried this a lot of times (since it can be done with any test framework plus a file watcher on any language) but it doesn't help on my workflow.
The integration with the code editor looks nice as long as it has a way to "jump to the first broken test", and show all the details of the error. I remember when I used to work on c# the test runner of resharper integrated and it was great. My current workflow is, I run the tests in the console and if some test is broken, I search the name of the test across the project to inspect.
Parallel test execution in javascript hasn't worked for me, most of the time I depend on some "state" call it DOM (browser), or call it a test database (node). The fact that I can assume that the runner run one test at the time makes my tests and the before/after code simpler.
Yep, wallaby can jump to failing test(s), error sources, show error details inline and much more.
Parallel execution in wallaby works fine with browser "state". Imagine running a half of your tests in one browser tab and another one in a second tab - that's what wallaby does but in 6 or 8 or N processes. As long as your tests set up context for themselves and don't depend on each other (and they shouldn't) - it all works.
Thanks for sharing!
Karma was built to run all of your browsers tests in as many different browsers as possible.
Wallaby.js focuses on seamless integration with many code editors and on delivering instant feedback from your (both browser and node.js/io.js) tests.
http://i0.kym-cdn.com/photos/images/newsfeed/000/538/731/0fc...
Even if it does run in a real browser, cross-browser issues are common enough in my work that my TDD loop always includes multiple browsers. I wouldn't be willing to give that up for what Wallaby offers.
Part of the reason I'm interested in something like Wallaby is that running in multiple browsers is slow--but if I could run just the right subset, it would be fast enough for my needs. (And Karma still runs about 200 tests / second on my mid-2002 MacBook Pro, across 10 browsers, including IE VMs, so it's not like Karma is that slow.)
Karma is not slow, but some of our tests may be. Wallaby just allows not to run them if we are not editing anything that affects them.
Cross browser issues are always a pain, I know what you mean. However, I have realised that I can write the bulk of my code without worrying too much about them.
When I'm writing the bulk of logic, especially with TDD, I found that it's more efficient to run tests as fast as possible in the fastest engine and care about running across all browsers much less frequently. Especially if you run tests as you type.
Later on, closer to the end of the iteration, when preparing to commit my changes, I surely run all of the tests in all browsers/smartphones/tablets that I support. Typically it just works, especially when your codebase is mature, you already know the majority of cross-browser issue sources and have something in place to avoid them. Even if it doesn't work, the issues are normally easy to solve. Overall, less context switching, more focussed work.
Anyway, it's just my experience (you can read more about the motivation behind wallaby.js in my blog post - http://dm.gl/2015/01/30/wallaby/) and we are planning to support more browser runners, or even just karma as a runner for wallaby, in future. Please feel free to vote (https://github.com/wallabyjs/public/issues/29) or create new feature requests.
Fast tests (< 1-5s) have a lot of value to me (although "test when I press save" is as good or even better than "test as I type," as far as I'm concerned), so Wallaby is something I'm interested in. I'm more likely to do manual test sub-setting than give up my cross-browser tests, though.
One potential customer's perspective; you can take it or leave it. :-) I'm not necessarily a good example of the mainstream. I've voted on the issue.
And what language/framework or other reason could possibly contribute to that long a test suite?
I do not work on SQLite, but here is something similar: http://www.sqlite.org/testing.html