Monday, June 10, 2013

From the streets of Test Driven Development: JavaScript

"... Let the unit testing drive your design. Write a unit test that specifies what should be done. Do a couple of variations if necessary, and then write the code that does the job. Switch back and forth between the unit tests and the code, refactor and clarify.

If you don't trust your code, write another unit test that provokes side effects. Do that until you feel confident. Then go home and have a good night sleep. ..."

(Okay, it's me. I said that. I just thought it would be cool having a quote as an intro to this post)

Test driven JavaScript? 

Write a simple test, write a simple function. Done. 

That was the twitter version. What about the blog version? I think test driven development (TDD) is a good tool for helping you write code with high readability and a design with ease of use in mind (sometimes).

As a tool for testing (no matter what programming language you choose) TDD is overrated and quite often misunderstood. Probably because of the word Test in it, don't you think?

Before we start, I want you to don't care about stuff like code coverage, what frameworks to use and every line of code should have a corresponding unit test. That last thing is just nonsense. Think about the result, the code that actually will run in the production environment. The result is important. No matter how many nice unit tests there are, the result should be as simple as possible. Simple, as in easy to understand, maintain and refactor.

Simple is really difficult! I have failed with that many, many times (and still do, but never give up trying). What I have learned is that having a bunch of unit tests doesn't compensate for unnecessary complex production code. With or without unit tests, complicated code still sucks.

Also, don’t start the TDD journey by evaluating all those tools and worrying about continuous integration scenarios. Leave that for later. 

Do it the Agile way: experiment and learn.

"- Cool, I know unit testing already. I use that when writing C#. But TDD with JavaScript, how?"

If you come from a C# or Java background and already write unit tests (but have little experience of JavaScript) I think test driven development will help you understand and explore the language.

TDD has helped me to break free from the mindset chains of C# and Java style programming. JavaScript is not object oriented like in those languages. There are no classes, it is a language of functions and objects (and functions are objects). Objects can inherit from other objects and every object has a force field surrounding it (aka Closures) that is really powerful. Maybe we could call JavaScript the class less society? ...Because everyone has a function there.

Enough. (Want the basics? Check out my talk "Rediscover JavaScript" from dotNetConf.)

I have made a 15 minute video on how test driven development can be done with JavaScript and tried to write the code with simplicity in mind. I have avoided the common JavaScript language gotchas, like prototype inheritance and pseudo classes with the new or this keywords. In this video I use only one tool for unit testing (QUnit).

Take a look at the video and please share your thoughts about it!

No comments: