larsthorup

https://www.fullstackagile.eu/blog/

I mostly blog about JavaScript techniques and testing techniques, often focused on performance.

Yes, using #feature:name=value. This makes it easy to share a URL to someone who wants to test a not yet enabled feature

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.

Doesn't appear to work for us

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"?

In Denmark, our MobilePay system is often used to provide cash between strangers when needed.

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...