Should you use a tool at all? One code file with the flags, and a small piece of router middleware that allows the URL to override the value of flags, and then just if statements. This has served me well on the past 3 frontend projects I have built.
I did an experiment with the Chrome Debugging Protocol the other day. It allowed me to write and run acceptance tests in pure JavaScript with no Selenium, Java or binaries (except for Chrome of course). See working proof-of-concept here: https://www.npmjs.com/package/websteps
I have recently ventured into auto-mocking, see http://zealake.com/2015/01/05/unit-test-your-service-integra..., which allows me to run super fast unit-tests, that are really doing end-to-end testing, giving me 100's of end-to-end tests per second. Is that the same line of thought as your "independent slices of implementation and pushing sample input/output in"?
That's a really interesting idea. It looks like you're capturing and proxying the latest backend request/response patterns used in its test suite into a frontend test requirement so that you can run them both independently, and thus much faster, whilst still keeping most of the assurances of an end-to-end test. I'm going to have to think about applying that approach to my own projects.
What I actually meant is slightly more literal. The backend of my latest web project is 100% web client invocable functions in AWS Lambda. The frontend is a static site built in redux with sagas. The view is a dumb layer mapping state to html and dispatching redux actions which are picked up by the sagas. Each saga only invokes one lambda function, though does send/receive signals with other sagas. Responses break down into state changes which map to a single react view.
By taking this path all implementation can be visualised as discrete slices of logic. Moving signals `up` and `down` the slice requires request/response patterns between the components. To test, I run a script against the developer staging area which sends API calls to each function and diffs the result with expected response back. It is fragile to any change which affects API responses, but is dumb enough that it gives me confidence to flip the switch turning staging environment into production. Its super easy to maintain and update, though I suspect it'd be difficult to apply the approach to more complex application domains (this is a virtual telephone number service).
PayM (and MobilePay I gather) is basically a table of bank account details keyed by mobile phone numbers, so you can make a standard electronic bank transfer to someone's account number and sort code, with only knowing their phone number. It's handy, but seems a bit different from crowdsourcing ATMs and Bitcoin deposits?
You are right, and I considered adding that question as well. JavaScript has so many quirks that it's very tempting to use a transpiler. However I do not have any experience with transpilers myself. I also don't see any of them getting a lot of traction, not even CoffeeScript. And then there are people moving towards vanilla JavaScript. It is definitely an important question.
I write JavaScript unit tests using QUnit on one project and Jasmine on another. I can run thoses tests in a browser when debugging, and from the command line for continuous integration. Unit tests are fast and much more robust than Selenium tests. On one project we curently run 800 Jasmine tests in less than 20 seconds. I have written a series of blog posts on the continuous integration side of front-end JavaScript unit testing: http://www.zealake.com/2012/12/25/run-all-your-javascript-qu...
I'd like to see customer involvement much earlier. You could start out solving a specific problem for a customer who will pay you to do it. If that particular problem seems to be relevant for other customers, you can make it into a product. This only requires that your initial contract with the first paying customer allows you to do this, but if you allow the price to go down this should not be a major obstacle. You should probably still go through the intuition and market analysis phases, but the benefit with this model is that the idea will have passed the testing phase already.
I don't know if I should smile because this is a nice example of how to find a simple and pragmatic solution to some problem you have. Or if I should cry over all the bugs they are now going to track instead of fixing them, see "Why Bugs should not be Tracked" at http://www.bestbrains.dk/dansk.aspx/Artikler/Why_Bugs_should...
I mostly blog about JavaScript techniques and testing techniques, often focused on performance.