Recently in our software engineering class we tackled a topic I’ve really wanted to dig into – testing. I know from my work at Greps how highly valued really extensive and logical unit testing is but I’d never written an actual test before today. I’m sure my excuses are fairly typical – assuming the happy path(s) from the initial concept and using a tight schedule to cram more functionality into the app rather than make naive assumptions.

As Francois stated in our lecture so much can go wrong at levels of abstraction beyond your control. When working in a large codebase how much we depend upon tools and features in our IDE’s heavily – I can easily imagine introducing bugs when we assume the IDE will always catch an issue. This lecture and research went a long way to making me realise how much needs to be to provide a fundamentally sound piece of software. 

The notes below highlight the basics of testing as a whole which was valuable to dig into as I had previously zoomed in on unit testing only.


  • Validation testing – is the application working as expected?
  • Defect testing – test cases should expose defects / should fail
  • Development testing – finding bugs and defects during app creation 

In development testing three phases are passed through:

  • Unit testing (specific functions)
  • Component testing (interfaces)
  • System testing (compatibility / race conditions)
  • Release testing – non dev team testing
  • Requirements based testing – systematic approach to test case design
  • Scenario based testing – realistic, typical use cases
  • Performance based testing – focus on load – find limits
  • User testing – alpha/beta 
  • Test driven development – write the tests before the code – valuable process on critical systems infrastructure

A prominent JS dev I read Eric Elliot is a proponent of TDD and highlights benefits also made in the lecture and going as far as saying you should ‘always’ code in this way, and that the slower initial development pays for itself many times over in the future. This is because: 

  • 100% code coverage
  • Regression testing developed incrementally
  • Easier debugging
  • Tests acts as documentation providing a more understandable code base

* * * Check out my github for some basic unit testing in JS examples

Leave a Reply