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!

829e745fc00d15823f96bffb92577d51?s=128

Matheus Albuquerque

November 21, 2016
Tweet

More Decks by Matheus Albuquerque

Other Decks in Programming

Transcript

  1. None
  2. TESTING

  3. our DIFFICUL TIES

  4. XCODE SUCKS (!!!)

  5. None
  6. × 493534043

  7. Untestable CoDE

  8. None
  9. It is not possible to reuse this method for OTHER

    LEVELS
  10. None
  11. The method has multiple responsibilities

  12. None
  13. depends on a mutable global state; cannot be predicted by

    merely reading the source code
  14. × tightly coupled to the data source; × violates Single

    ResponsibilitY; × hard to predict & maintain ( non-deterministic behavior)
  15. Impurity is toxicIC

  16. Write Good UNIT tests

  17. ✓ Easy to ReaD; ✓ Easy to write; ✓ Reliable

    ✓ Fast × Truly unit, not integration
  18. LESSONS learnt

  19. BDD Frameworks

  20. None
  21. None
  22. QUICK + NIMBLE =

  23. focus on what the feature provides for the end user,

    not implementation.
  24. None
  25. wrap method tests in a describe block

  26. wrap scenarios (succeeds, fails, ETC.) into a context block

  27. Wrap multiple side-effects IN multiple it blocks

  28. ๏ wrap method tests in a describe block; ๏ wrap

    scenarios (succeeds, fails, ETC.) into a context block; ๏ Wrap multiple side-effects IN multiple it blocks
  29. xctool

  30. None
  31. Control the build system, and you control the destiny of

    the language, its ecosystem, and community.
  32. OTHER CI SERVICES

  33. None
  34. None
  35. None
  36. WORK WITH PURE FUNCTIONS

  37. ✓ 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.
  38. UNIT TESTING Games

  39. ✓ 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).
  40. THE RESULTS

  41. ✓ UNIT TESTING ✓ INTEGRATION TESTING × END-TO-END TESTING ×

    CODE COMPLEXITY TESTING × PERFORMANCE TESTING
  42. THE future

  43. “TIREM AS CRIANÇAS DA SALA”

  44. THANKS