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

Тестирование в Go

Тестирование в Go

- коротко о главном пакете "testing" (TestXXX, BenchmarkXXX, go test)
- почему иногда ассерт либы это плохо
- mock
- suite testing

Alik Khilazhev

April 28, 2019
Tweet

Other Decks in Programming

Transcript

  1. План • Основы (go test, TestXXX, BenchmarkXXX) • TableDrivenTests •

    assert либы: за и против • Mock • suit testing
  2. asserts за и против • No doubt assertion libs can

    reduce typing and repetition. • Reductions in typing with assertion libs are not profound. • The necessary repetition without assertion libs can be minimised. • Some repetition locally can increase readability at no great cost. • Some assertion libs tend to reduce the value of tests as documentation. • You are adding another (often large) library dependency with associated maintenance overhead, bugs, life cycle etc. • It is a commitment that will stay with you for a long time, and it is expensive to undo. http://danmux.com/posts/the_cult_of_go_test/
  3. asserts за и против • Type safety is often dropped

    - or needs explicit knowledge, or is only enforced at runtime. • There is a DSL to learn - often considerable - an extra burden on the team and new members forever. • The libs often introduce multiple ways to achieve the same thing, or worse: similar but subtly different ways. • It does not resolve the infighting - a new dev will argue for their favourite lib. • Adding the assertion lib in the middle of a project adds an annoying inconsistency. http://danmux.com/posts/the_cult_of_go_test/