Porque é que testamos o nosso software? Se eu quiser que o código que faço não quebra código antigo, preciso de testar o meu software todo quando faço uma alteração. Mas isso seria de doidos, não seria? Se calhar, se houver umas coisas que são capazes de testar e re-testar o meu software, eu podia ensinar-las a testar, enquanto vou escrevendo mais código, mais funcionalidades e melhorar o que já tenho!

Nesta sessão vamos olhar para a pirâmide de testes, cortar-lhe o topo de UI, ver como é que podemos usar Xunit para implementar os nossos testes automáticos e como é que conseguimos correr estes testes. Uma breve introdução sobre testes automáticos e, de seguida, demos demos demos, da utilização de Xunit 2.2.0, com contextos, factos, teorias, coleções, dados, disposables e excel. Sim, Excel. 

Vamos também ver de relance algumas ferramentas auxiliares como Moq e Shoudly para ajudar na construção dos nossos testes.

Sendo cada vez mais premente e óbvia a necessidade de ambientes de Dev/Test que sejam consistentes e fácil/rapidamente replicáveis, é imperativo deixarmos de ter mil e quinhentas versões de um dado motor de dados ou de um dado sistema de eventos instalados em cada máquina.

Máquinas virtuais para cada motor?!? Máquinas virtuais para cada combinação de configurações?!? Os recursos das máquinas de desenvolvimento e testes devem ser infindáveis…

Mandem entrar o DOCKER!!! LONG LIVE THE WHALE!!!

Nesta sessão vamos ver o que são imagens e containers, como criar cada um deles e como correr as nossas aplicações/motores de uma forma eficaz, replicável e consistente.