Upgrade to Pro — share decks privately, control downloads, hide ads and more …

blau: A few notes on testing

blau: A few notes on testing

This is ~5 minutes pitch on which I share a few thoughts about good & bad practices we committed when it comes to coding blau, how those affected our tests, a few useful tools we found during the process and other cool stuff!

Matheus Albuquerque

November 21, 2016
Tweet

More Decks by Matheus Albuquerque

Other Decks in Programming

Transcript

  1. × tightly coupled to the data source; × violates Single

    ResponsibilitY; × hard to predict & maintain ( non-deterministic behavior)
  2. ✓ Easy to ReaD; ✓ Easy to write; ✓ Reliable

    ✓ Fast × Truly unit, not integration
  3. ๏ wrap method tests in a describe block; ๏ wrap

    scenarios (succeeds, fails, ETC.) into a context block; ๏ Wrap multiple side-effects IN multiple it blocks
  4. Control the build system, and you control the destiny of

    the language, its ecosystem, and community.
  5. ✓ The function result value cannot depend on any hidden

    information/state that may change as program execution proceeds, nor can it depend on any external input from I/O devices ✓ evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.
  6. ✓ much of the logic depends on semi-deterministic sources (e.g.

    graphics hardware, input timings, the frame rate) ✓ much of the output is hard to measure (e.g. on- screen graphics, sound effects) ✓ OTHER PARTS ARE almost meaningless outside of the full game context making (eg. complex reactive AI, physics simulations).
  7. ✓ UNIT TESTING ✓ INTEGRATION TESTING × END-TO-END TESTING ×

    CODE COMPLEXITY TESTING × PERFORMANCE TESTING