8-bit Super Mario Bros was the very first video game that I have played as a kid. Later there were no less awesome Battle City, Chip ‘N Dale, Teenage Mutant Ninja Turtles, Duck Tales, Battletoads, Darkwing Duck and many more. Those happy days, when I couldn’t even imagine that I’m going to become a programmer.
Many years later, when I became a programmer and had spent several years in the industry, I was watching the “Inventing on Principle” talk by Bret Victor. I am pretty sure, many of you have seen the talk, and even know a few software development tools inspired by it or just following the similar ideas.
As many of you, I have been amazed how in the presentation Mario looking dude jumps higher as we change the velocity, or how the tree blossoms right when we change the code.
We are also amazed when in some demos we change some code on a web page, right in DevTools or some other tool, click some button and see the result without the page reload.
These ideas are great and inspiring, but then we get back to our daily job to find out about the cruel reality.
First, it gets annoying very quickly to switch between our code editor and our browser to make Mario jump.
Later, some other developer changes the game level, everything suddenly breaks, it’s 9pm and we sitting at work and manually making Mario jump again and again.
Or worse, your version of jumping Mario is actually a button in a form somewhere deep inside your web application. And to click the button that would run some ‘live’ reloaded function, you have to do several steps each time before that function gets executed.
So, why does it look nice in all those presentations and doesn’t work for you?
The reason is simple and obvious. Your application complexity goes beyond simple demos and vanilla live editing approaches don’t scale. You don’t just have a simple
requestAnimationFrame callback or a single form hosted right in your
index.html. Your code changes are not limited to some easily hot-swappable ones.
Moreover, you pretty much always have to set up some context before executing any code and there’s no auto-magic solution to create/restore a desired context for your hot swapped code execution. You may need to manually take like 5 different steps before freaking Mario can jump or before you can click that button again to trigger your hot-swapped code. And all that ‘live’ and ‘hot’ quickly become no more attractive than your old-school coding approaches, if not less attractive.
The answer is yes. Automated and instant feedback beyond simple prototypes is possible with recorded, runnable, relatively small/fast and isolated scenarios. We have had the name for those for a long time and the name is tests. TDD/BDD or not, Given-When-Then or Arrange-Act-Assert, test first or after, or mixed - the important thing that tests have to be written.
When you are writing and later maintaining the bulk of your application logic, it’s not the visual image of jumping Mario that helps you making your inventions. No doubt, visualising things can help to get things started, then later to get a feeling that it is all real. To get a realisation that your app is not just a combo of your Controllers, Models and Views, but something alive. Surely, you may occasionally check that your Mario looks good and jumps when you press your keyboard keys. You may even write some E2E test for it.
But you don’t need your browser to make your Mario jump again and again. You don’t need to see the sky background every time, you don’t need to press your keyboard keys manually. Not only you can be “inventing on principle”, you can automate your invention process and make it more focused and efficient.
If you need to check something about how Mario jumps, just record the fact that Mario can jump into that hole as a verifiable and fast spec/test. Make it work for you not just once or twice, but when you change the size of the hole, when you change its position, when you change Mario to Luigi, or even to Scrooge McDuck.
So for the most part of your work: get rid of what you don’t need - close your browser, put on your headphones, open your code editor and nothing else, and do the bulk of your work efficiently. Write tests and code, let right tools to run it automatically and without distraction, get an instant feedback as you type.
At the end of the day, it doesn’t matter if your running program is reloaded or not, what is running your program and how it reloads it, as long as the feedback for your code changes is close to instant.
The answer is using the right tool.
First, running tests that you don’t need to run is a waste of time. If you changed one test or some code that is covered only by few tests, then why do you need to run hundreds of them? You wouldn’t want to complete all levels of Mario game every time you change princess Peach rescue scene, would you?
Second, getting your tests feedback somewhere outside your code editor, or even somewhere far from the line of the code that you are editing, is also not good enough anymore.
And if you’d like to get some visual feedback, you can use wallaby feature to display a screenshot of the test result. It supports not only HTML and CSS, but also SVG and Canvas. So if your test makes Mario jump, wallaby can show you jumping Mario, just like the calculator with buttons and screen in this video.
Most importantly, wallaby.js goes way beyond shiny simple demos, it really helps in real-world applications.
Worked on reducing down the 30 second wait for 1800 angular unit tests to run in Karma. Got it down to, well, instant with @wallabyjs :D— Andrew Shelton (@Sheltonial) March 4, 2015
We support various technologies and have a few repositories to get you started with wallaby.js quickly:
- Calculator for browser environment
- Calculator for node.js and io.js environment
- Wallaby.js with require.js app
- Wallaby.js with angular.js app
- Wallaby.js with react.js and JSX with babel and react tools
- Wallaby.js with browser ES6 via babel (former 6to5) preprocessor