Sick picks from Frontend Con 2018 @ Warsaw, Poland

What a cool bunch of super heroes! (Screenshot from https://frontend-con.io/)

Frontend Con 2018, thank you.

My sick picks…

…and their takeaways

Test Driven Development or TDD

Enter TDD.

I’ve always wanted to dive more into TDD, or Test Driven Development, and these talks convinced me I should: ultimately it saves time and gives you confidence in your code. It gives you some assurance that the application works, that refactoring did not break anything and that adding a new feature did not break anything either.

My current understanding of TDD, beyond the Red-Green-Refactor, is that you should ‘explain’ what your app does in some high-level way: staying away from testing implementation details too much is really necessary as refactoring becomes painful otherwise.

It’s important to write unit tests, namely tests ensuring a simple function does what it says it does, but integration tests should be the aim. They ensure your mega-component or your page or even your application work as intended.

Integration testing: will all these pieces fit together? Photo by Alexander Andrews on Unsplash

Write property based tests

Of course, example based tests are great: they are easy to write and easy to understand. They sort of tell you a relatable story, and as such document to an extent how your code works.

But they’re not enough.

Following TDD, you could create the following test

describe('capitalize', () => {   expect(capitalize('warsaw')).toBe('Warsaw');});

and write the following function to make it pass:

function capitalize(text) {
return 'Warsaw';
}

If this was your only test, you would assume that capitalize does what it says it does, when in reality it’s returning “Warsaw” for any string your feed it.

Even though this is a fairly simplistic example, you get the idea: you’re only testing so many special cases with example based tests; they likely don’t cover all the possible cases.

Some nasty bugs only appear after some odd steps, and manual testing would surely fail to discover them (e.g. Spotify reporting such a case here). Even 100% code coverage is no guarantee: Maciej Myśliński explained that adding property based tests to React Final Form Arrays (which has 100% code coverage), he was able to detect 10 bugs, 4 of which were already mentioned in issues. That’s an impressive 6 new bugs discovered.

Catching bugs with fast-check, Photo by Cole Keister on Unsplash

Since you want your tests to pass on randomly generated data, you need to find assertions that would work in every instance, hence the name property. For example, if you want to sort an array of numbers in increasing order, you expect the result of your sort function to be as follows:

  • the output should also be an array (type)
  • the output should have the same length (size)
  • the entries of the output should still be numbers (shape)
  • each entry should be smaller than the next one (sorted in increasing order)
  • sorting twice should yield the same result as sorting once (idempotence).

Using a library called fast-check to generate random data, if your test suite fails on that random data, the library provides you with a minimal counter-example of why your test failed— I find that awesome. To make sure this random occurrence where the test failed is not lost (the likelihood to have the same counter-example being generated twice is quite small…), you add it in your list of example based tests.

That’s right, the final shape of your test files should look like:

  • example based tests at the top, to quickly communicate what the functionality you’re testing does
  • property based tests, ensuring the tests are not just passing on the selected few examples.
Strong and robust tests, Photo by Ben White on Unsplash

A framework to approach web performance

Wait: this is on paper, and sort of theoretical knowledge. What we need now is a proof by fire and actually release the app to production.

Sacrebleu, it’s so slow!

Where do you even start to understand why it’s slow? How do we improve performance?

We need to identify what Nicolas Goutay calls the Value Stream, and he proposes the following model of all the different steps involved in getting your user to see your web-application:

Slide 17 from Nicolas Goutay’s talk

This break-down of all acceptable times makes it easy to pinpoint where you need to act for your application to be faster:

  • Maybe your bundle size is too big, so you might need to consider reviewing your build process: did you minify, uglify and gzipped your bundle, etc.?
  • Maybe your are loading too many assets or unoptimized assets or from slow origins: consider using fewer fonts, better optimized images, and serving assets from a CDN, etc.
  • Maybe your API calls are taking too long because your backend is not ready for that much traffic: either you throw money at the problem by scaling up resources or you get these database queries optimized, etc.

In addition, you also know which steps went well according to your benchmark and so any work there would bring the least value.

One other takeaway from that talk was the human aspect of building applications as a team: without proper communication, it’s really hard to coordinate and have every individual’s efforts be the most effective for the goal at hand.

The story of Nicolas’ endeavour to get his team passionate about performance is really inspiring: one person can bring about significant change within a company and drive the existing culture into another direction.

This can take the form of introducing tooling (I really like for instance the CI test checking the resulting bundle size) or methodologies like the Value Stream mentioned above. It also goes by empowering people to share their knowledge and discoveries, for them to feel comfortable asking questions freely and early, to reflect constructively on their failures and celebrate their successes. What a great program!

“Un pour tous, tous pour un !”, Photo by rawpixel on Unsplash

Just scratching the surface

  • playing with machine learning and AI,
  • Vladimir Novick showed that AR and VR are already there in React Native,
  • SoundCloud’s XBox app contains a garbage collector for Redux written in JavaScript.

Exciting times!

If you would like to get some less polished account of the conference, with links to slides and lists of resources, you can have a look at my notes on GitHub.

I look forward to attending my next conferences this year! If you have any suggestions, please send them my way! In the meantime, thank you for reading this article and I welcome any feedback you may have in the comments.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store