Demo-Driven Development with Polymer

We have been using Test-Driven Development (TDD) for our Java backend for a long time. We even used TDD for our old GWT frontend application.
Then came Polymer, and we had to change our game.

No tests without code

Migrating from GWT to Polymer raised an interesting challenge: There wasn’t much left to test. Most of the code had simply disappeared. For example, Polymer’s data binding replaced all our explicit setting and getting in GWT:

<input is="iron-input" bind-value="{{value}}"></input>
You say [[value]]

On the one side, that’s great news: no more gluing code, only “real” business logic — the stuff that should actually be tested. On the other side, the gluing does matter: the most magical calculation isn’t useful if our application forgets to print the result to the screen.

Demo the untestable

We therefore moved to Demo-Driven Development. Nowadays, the first step of writing a new element is creating a trivial demo page for it:

<my-element><my-element>

The demo gets extended as we add features, e.g:

<template is="dom-bind">
  <my-element no-results="[[noResults]]" result="{{result}}"><my-element>
  Result is [[result]].
  <paper-checkbox checked="{{noResults}}">Empty results</paper-checkbox>
</template>

[See paper-search for a complete example.]

With the demo we get immediately feedback what using the new element feels like, if the layout looks properly, and if our magic number is printed to the page. And only the magic calculation itself, we cover with unit testing.

Free bonus: Turns out that human beings understand much better what an element does based on a demo than by reading unit tests.

Happy coding!

Want to learn more about Polymer? Have a look to all our Medium posts on Polymer.

Photo: woicik