Wybór języka

CI

Do tej pory prezentacja była wygłaszana tylko po angielsku. Jeśli ktoś byłby chętny na wersję po polsku, to zapraszam do kontaktu ;-)

Integration tests are nice. We all know that and love using them, don’t we? It’s just using all those databases, message brokers and other things as real dependencies, only wrapped by Testcontainers, might result in a really heavy CI/CD pipeline and developers’ attitude to never run them locally, because they’re so slooooooooooow. What if I could show you a number of techniques, mindset changes and tricks to get your integration tests shortened from quarters to seconds? Would that be interesting for you, to benefit from the confidence integrations tests give you, before you’re able to brew a fresh coffee? It’s really not about re-inventing the wheel, but using it the smart way.

Niektórzy ludzie narzekają, że nie wykonują testów integracyjnych “ponieważ zajmują za dużo czasu”. Dobrze, interakcja z rzeczywistymi zależnościami czasami nie może być skrócona, ale z pewnością istnieją sposoby na szybsze uruchamianie baz danych, brokerów wiadomości i innych, jeśli używasz do tego Testcontainers.

W tym wpisie będę używał języka Java. Jednakże, ponieważ Testcontainers jest (z pewnego punktu widzenia) wygodnym sposobem na współpracę z kontenerami zgodnymi z Dockerem przy użyciu języka programowania, który znasz, to samo podejście można zastosować również do innych technologii. Jestem pewien, że po zrozumieniu idei można ją przetłumaczyć na Go lub C#.