W poprzednich częściach cyklu skupiałem się na korzyściach płynących z TDD. Jeżeli ta metoda wejdzie nam w krew, te korzyści zachęcą nas, abyśmy pisali w ten sposób zawsze i wszędzie. Motywują nas do tego również eksperci mówiący, że każda linia kodu powinna być przetestowana. Okazuje się jednak, że nie zawsze testowanie wszystkiego na siłę jest dobrym rozwiązaniem. W tym artykule opiszę sytuacje, kiedy nie opłaca się używać TDD. Programując czasem natrafiamy na problemy, co do których nie mamy z góry...
Strona głównaSztuka programowania
Sztuka programowania 2854 dni, 17 godzin, 18 minut temu 190 pokaż kod licznika zwiń
Podobne artykuły:
- Strona Szoguna - NCrunch - Jakie to, k...a, dobre
- A Second Look at Unit Testing | DariuszWozniak.NET
- Mockowanie out - Dariusz Woźniak — Blog
- Kurs TDD cz. 19: Mock, stub, fake, spy, dummy | DariuszWoźniak .NET
- [EN] TDD with TypeScript, AngularJS, and Node.js
- [EN] Working Effectively with Legacy Code
- Dlaczego zainteresowałem się TDD? - ucgosu.pl
- Kurs TDD część 6: Dobre i złe praktyki testów jednostkowych | DariuszWozniak.NET
- MemoryStream jako zamiennik dla wyjścia konsoli (lub pliku)
- Kurs TDD część 4: Nasz pierwszy test jednostkowy | DariuszWozniak.NET
- [EN] Testing in Agile teams - how to iteratively take care of project quality | Future Processing