Start writing tests as they were documentation

«But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.»

— Edsger W. Dijkstra, 1972

Main tests objective is to make legacy code disappear.

  1. There are no tests for such functionality.
  2. We need to alter many tests significantly.
  3. We do not know all supported functionalities.

An event listener testing example.

describe('addListener', () => {
it('should add a callback to the queue', () => {
dispatcher.addListener(cb);
expect(dispatcher._queue).toContain(cb);
})
})
describe('deliver', () => {
it(
'should invoke queue callbacks with the received argument',
() => {
dispatcher._queue.push(cb)
dispatcher.deliver('message')
expect(cb).toHaveBeenCalledWith('message')
}
)
})
it('delivers messages to listeners', () => {
dispatcher.addListener(cb)
dispatcher.deliver('message')
expect(cb).toHaveBeenCalledWith('message')
})

Conclusion.

  • Start writing a test for each main functionality.
  • Then their exceptions.
  • Refactor tests until they are easy to read and understand.
  • Never use “private” properties in testing code.
  • Verify that testing code should be copy-pasteable to new production code.
  • If some functionality works but has no test, do not use it.

--

--

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
David Rodenas, Ph. D.

David Rodenas, Ph. D.

I like to write stories about how we understand and apply software engineering, and to make us think about what we could improve.