Beginne klein.
Unit Testing (und automatisiertes Testen im Allgemeinen) ist kein Allheilmittel, trifft nicht immer auf jede Situation zu und kann ein wenig gewöhnungsbedürftig sein. Trotzdem, wenn du Software schreibst, die du verkaufst oder auf die dein Unternehmen angewiesen ist, empfehle ich dringend, es zu übernehmen. Du wirst überrascht sein, wie viele professionelle Entwicklungsfirmen das nicht tun.
Zunächst einmal solltest du dich mit den Mechaniken vertraut machen, wie man mit deinen Entwicklungstools Unit Tests erstellt und ausführt.
Dann fange mit einer neuen (vorzugsweise kleinen, aber nicht unbedingt trivialen) Klasse oder Methode an, die du testen möchtest. Tests für bereits bestehenden Code zu schreiben, hat seine eigenen Herausforderungen, deshalb solltest du entweder mit etwas ganz Neuem beginnen oder mit etwas, das du umschreiben wirst.
Du wirst feststellen, dass es einen Einfluss darauf hat, wie du den Code schreibst, wenn du diese Klasse oder Methode testbar (und daher wiederverwendbar) machst. Du solltest auch feststellen, dass das Nachdenken darüber, wie der Code getestet werden soll, dich dazu zwingt, das Design jetzt zu überdenken und zu verfeinern, anstatt es "irgendwann später, wenn es mehr Zeit gibt" zu tun. Selbst Dinge wie "Was sollte zurückgegeben werden, wenn ein ungültiger Parameter übergeben wird?". Du solltest auch ein gewisses Maß an Vertrauen haben, dass der Code genau so funktioniert, wie du es erwartest.
Wenn du von dieser Übung einen Nutzen siehst, entwickle sie weiter und fange an, sie auf andere Teile deines Codes anzuwenden. Im Laufe der Zeit wirst du immer mehr Vertrauen in deine Software haben, da sie immer nachweislich korrekter wird.
Die praktische Herangehensweise half mir, das Thema besser zu verstehen als viele der Lektüren und half mir, die Lücken von Dingen zu füllen, die ich einfach nicht verstand. Besonders im Zusammenhang mit TDD. Es war gegen meine Intuition, bis ich es tatsächlich ausprobiert habe.
