When I started using ES6 (or JavaScript2015, ECMAScript2015) I realized that I was looking around for posts, reading them and as soon as I understood how the new function/feature worked I left. Diving deep and understanding things was just a way I then did using TDD, by using the new function or feature. So why not make this accessible for others. That’s how ES6 katas came about.
When to start with ES6?
Now! I would say, dive in and get started. There is no time to loose, ES6 is an official finalized standard, it’s not a draft anymore. So it will come your way sooner or later. And even better it will evolve even faster from now on, hopefully.
I just had a discussion with a friend, he asked “Why doesn’t node support ES6 yet?”. The simple and short answer was use `npm install babel && babel-node index.js` instead of `node index.js` and you have all ES6 features. Why node is not completely supporting ES6 is not part of what I want to discuss here, it has dependencies on the V8. But nowadays we have such a huge eco system in JavaScript that there are ways that allow us to use transpilation and CoffeeScript made this very obvious, that this is a way to go.
ES6 and TDD?
There are multiple ways of learning and trying out ES6. But for me the native way was using it. And since I am quite accustomed to use TDD it was a no-brainer to enable ES6 in TDDbin and use it there. I started exploring if and how ES6 works in TDDbin.
It might be discussable that TDD is the right tool to learn a language. It is just one way. And it allowed me to learn and focus on one thing at a time. We all know that once we start using a feature somewhere and there is lots of other (code) noise around it the focusing on learning that one feature gets lost. That’s why I started exploring ES6 features in the TDD style. I think the first thing I tried (at least that’s the first kata) was template strings.
it('prints x into a string using ${x}', function() {
var x = 42;
assert.equal(`x=${x}`, 'x=' + x);
});That actually made me want to try more. And always ensure that my learnings stick. It also made me kind of want to keep track of what I learned, so I really liked the test result output, which just showed “yeah all green, you got it all right”. It felt cool.
When I released the first katas I was pointed to ruby koans, which existed way before ES6 katas. So I was playing with the thought of renaming it to ES6 koans, but in the end I just didn’t.
One Kata a Day, at 9:55am
In the beginning I didn’t know how serious this kata thing will be. Anyway, I pushed the stuff into a repo. Actually the first kata I ever pushed was on how to use mocha and node’s assert. Since this was what TDDBin uses initially. This was not really a kata, but a kind of documentation to see how mocha and assert can be used. This was the initial thing that gets loaded into TDDBin so anyone new to it can use it right away.
Since stuff landed in a repo it meant I can actually link to it. So I started out cautiously tweeting the katas every day. I didn’t know for how long I can keep it up. After there had been a couple of them out in the wild my colleague Tobias told me why not collect them all on one site and just link use the github search to find them all. Cool idea. Nothing to maintain and it auto-updates whenever a new kata ended up in the repo. How cool is that?
Pressure increased. From the beginning on I thought it was a good idea to post a kata always at 9:55am GMT+2, so you can just do a quick kata before the 10am stand-up :). I am not sure if all katas are simple enough to get this done, but hey it was a good story. From the beginning on I used the hash tag #es6kata, so you can find all katas in historical order.
Fun fact. You will notice that they all have textually written their ordinal number, so first, second, … In the beginning I just needed a pattern but later even this started to become a learning exercise. And I got eighth and ninth wrong in the beginning. I had to look them up. That was fun. So I kept numbering them. The word “thirtieth” was fun too. Gee, did I not know this stuff.
Kata Groups
The first ten or twenty katas I was still a bit insecure of how to write them and how to get a flow into the katas. I was overwhelmed by the wealth of new things that existed in ES6. I knew they need some structure. Looking at kangax’s compatibility table kind of gave me an idea of how to group the katas. It also showed me that there is lots of potential for new katas. There will be one-hundred katas easily just to learn the new ES6 features.
I knew there needed to be some kind of structure to it. Basically there are two kinds of kata groups. One the APIs, for example of `Object` or `Array` and the other is by features like destructuring, scoping, template strings, etc.
I sorted them into folders with the according names. And used those names as group names. It became ugly and not really helpful over time. Just a little while ago I switched to maintaining the meta info in a separate file, which is also used now to generate the kata groups. This allows for some niceties on the site, like additional info and the highlighting of the latest and easy katas. It also makes some better headlines and the links are more explainatory, or at least as good as the description is I gave it inside the meta info file.
How I create a kata
When I create a kata I try to write helpful text into `describe` and `it`, just the way I try to structure tests. They shall “tell a story”™ as Kent Beck says.
Starting a kata from the top hopefully makes the user explore the feature in more depth from top to bottom. When reading all passing tests the learnings should be the green test results, like here:
When reading the tests it is helpful to overread the `describe` and `it` and just see the text in there as the hint of what to do. Maybe using some other word for `it` could be helpful. It would be as easy as `smthg = it`.
The test description is supposed to make the user understand what the test tries to teach. I realize that there are multiple ways to solve a test, that’s why the description should be read carefully and the user shall try to modify the result accordingly. If that doesn’t work I would be really thankful for pull requests.
In order to lead the user to the result, the last line, where the assertion takes place should not be changed. This sometimes leads to unnecessary overhead in a test, I just didn’t find a better way yet. I rarely use the `___` space holder since it draws the focus on this spot and possibly leaves the rest unread.
Teach to Learn
So I hope the ES6 katas are helpful to some people out there. It was pretty awesome that HN picked it up last weekend and this drew some attention to it and the feedback was mostly positive.
