Automatyzacja projektu z MSBuild-em - 4a. TDD, prawie jak TestDriven.NET

Jul 17, 2008 - 2 minute read -

Wcześniej już wspominałem, jestem strasznie leniwy. Nie lubię pokonywać setek kilometrów myszką, nie lubię pisać dwa razy tego samego, nie lubię często naciskać Alt+Tab … i wpadłem na taki pomysł.

Test current solution Test current project

Teraz wystarczy zamapować klawisze, np…

Map keys

… i prawie jak TestDriven.NET :)

A teraz mała opowiastka … Ostatnio, w trakcie rozmowy rekrutacyjnej w ramach poszukiwania pracy, spytałem osobę, która  przeprowadzała ze mną wywiad, czy w swoich projektach wykorzystują TDD. Okazało się, że chcieliby, ale tak nie do końca bo mają testy własne napisane we frameworku X, który znają, a dostali jeszcze w spadku poprzednia wersję, którą miała napisane testy we frameworku Y i niby teraz trzeba by przepisać te testy a nie ma czasu etc etc ?!?!?

Ja wychodzę z założenia że lepsze unit testy jakiekolwiek, niż żadne. Framework się nie liczy. Oczywiście nie należy dopuszczać, aby każdy członek zespołu pisał przy wykorzystaniu innego framework-u. Gdy dostajemy testy “w spadku” wykonane w innym narzędziu to zamiast je przepisywać, lepiej je uruchamiać razem.

Dlatego w którymś z dalszych odcinków będę chciał się zmierzyć z uruchamianiem testów pod kilka platform za jednym przyciśnięciem klawisza. Ciekawe czy TestDriven.NET to potrafi ? Przyznam się że nie wiem.

Update: Na pierwszym obrazku, czyli “Test Current Solution” jest błąd. Czy znajdzie się osoba, która uważnie przeczytała poprzedni odcinek i będzie potrafiła go poprawić ?