Test Driven JavaScript Development

I put together a very basic website called TestDrivenJSDev.com as a companion for my presentation at HDC (Heartland Developers Conference). The website was not very easy to maintain, in order for me to make a simple grammer fix I had to do a full push up to BitBucket, which would kick off the build process to rebuild the whole site. Not very ideal. But it was temporary, so I lived with it. My big push was really getting the content up there for the HDC presentation.

At the same time I was looking at moving my personal onto a different provider and find a better domain name that reflected my major passions. I wanted to wait until the dust settled on my personal site. Then I would move TestDrivenJSDev.com over to my personal site. Well the time has finally come.

All the existing "lessons" I put together have been ported over. You can find them here:

About Test Driven JavaScript Development

This website is an offshoot of a presentation I gave at HDC 2014. The goal of the presentation and this website is to teach you the techniques on how to make your JavaScript better structured so it can be easier to test.

We, as developers, need to ensure our users are getting the best experience possible. Our users are the reason our websites exist. Asking our users to work in classic ASP.NET web forms is just not going to fly anymore.

That means more and more business logic needs to be pushed out of the back end and into the front-end. Not too long ago all of that logic was manually tested. If we were lucky a QA person or group of people would handle all that mind-numbingly boring testing. If we weren’t lucky we had to do all the testing ourselves. Manual testing will always lead to something being missed. Hopefully the bug missed is not something which results in a phone call at 2 AM.

Tooling and good practices has made it very easy to test the C# or Java code since the early 2000s. The good practices helped structure the code which made it easier to test. Following best practices meant putting code to hit the database in a separate class or project than the code that validates the data.

The tooling has existed to unit test JavaScript for at least a couple of years, but good coding practices have typically not been used. Often times the excuse was, “this is just JavaScript,” or “JavaScript is too hard to test.” Poorly written code is hard to test. The language choice shouldn’t even be in the conversation. If you apply some of the practices you learn on this site your code should be better structured and as a result easier to test.