Test-Driven Development in JavaScript

I’m in the process of redesigning elements of the Codemanship training workshops, and I’ve been spit-balling new demos in JavaScript on TDD. Rather than taking copious notes, I’ve recorded screencasts of these demos so I can refer back and see what I actually did in each one.

I thought it might be useful to post these screencasts online, so if you’re a JS developer – or have ambitions to be one (TDD is a sought-after skill) – here they are.

I’ve strived for each demonstration to make three key points to remember.

#1 – The 3 Steps of TDD

  • Start by writing a test that fails
  • Write the simplest code to pass the test
  • Refactor to make changing the code easier

 

#2 – Assert First & Useful Tests

  • Write the test assertion first and work backwards to the setup
  • See the test fail before you make it pass
  • Tests should only have one reason to fail

 

#3 – What Should We Test?

  • List your tests
  • Test meaningful behaviour and let those tests drive design details, not the other way around
  • When the implementation is obvious, just write it

 

#4 – Duplication & The Rule of Three

  • Removing duplication to reveal abstractions
  • The Rule Of Three
  • When to leave duplicate code in

 

#5 – Part I – Inside-Out TDD

  • Advantage: tests pinpoint failures better in the stack
  • Drawbacks
    • Risk the pieces don’t fit together
    • Tests are coupled closely to internal design

 

#5 – Part II – Outside-In TDD

  • Advantages
    • Pieces guaranteed to fit together
    • Test code more decoupled from internal design
  • Disadvantage: tests don’t pinpoint source of failure easily

 

#6 – Stubs, Mocks & Dummies

  • Writing unit tests with external dependencies using:
    • Stubs to return test data
    • Mocks to test that messages were sent
    • Dummies as placeholders so we can run the tests
  • Driving complex multi-layered designs from the outside in using stubs, mocks and dummies
    • Advantage: pieces guaranteed to fit and tests pinpoint sources of failure better
    • Risk: (not discussed in video) excessive use of test doubles un-encapsulates details of internal design, tightly coupling test code to implementation
  • More unit-testable code – achieved with dependency injection – tends to lead to more modular architectures

 

These videos are rough and ready first attempts, but I think you may find the useful as they are if you’re new to TDD.

I’ll be doing versions of these in Python soon.

Author: codemanship

Founder of Codemanship Ltd and code craft coach and trainer

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s