Czy TDD chroni przed głupotą?

Często słyszymy: “TDD powinno sprawiać, że oprogramowanie nie ma bugów“. A to bardzo mylne pojmowanie wszystkiego, co się za TDD kryje! I dla tej praktyki mocno krzywdzące, bo gdy się okazuje, że tak nie jest, to ludzie się zniechęcają.


Ale do rzeczy: czy TDD zwalnia z myślenia? Albo inaczej: czy z TDD nie można popełnić błędów?


Czy przetestowany kod jest poprawny? Uwaga, rocket science approaching:


Testy weryfikują, że kod działa tak jak chce tego programista, a nie tak jak powinien!


Zamiast się nad tym dalej rozwodzić, przytoczę przykład. Ujawnię swój własny wstydliwy zakamar. Miałem taki interfejs:



public interface IDetectInvalidOrders
{
bool IsValid(Order order);
}

A zaimplementowałem to tak:



public class InvalidOrdersDetector : IDetectInvalidOrders
{
public bool IsValid(Order order)
{
return order.Description == "invalid-order";
}
}

Logika sama w sobie jest prawidłowa: “biznesową niepoprawność” zamówienia w tym systemie oznacza się poprzez wpisanie w nim jakiegoś zdefiniowanego opisu, który w prawdziwym systemie pobieram z konfiguracji ale tutaj to uprościłem.


Testy? Owszem, są! Ba, były nawet napisane najpierw:



public class InvalidOrdersDetectorTests
{
readonly InvalidOrdersDetector _detector;
readonly Order _order;

public InvalidOrdersDetectorTests()
{
_order = new Order();
_detector = new InvalidOrdersDetector();
}

bool execute()
{
return _detector.IsValid(_order);
}

[Fact]
public void detects_invalid_order_based_on_description()
{
_order.Description = "invalid-order";

var result = execute();

result.ShouldBe(true);
}

[Fact]
public void does_not_detect_order_with_no_description_as_invalid()
{
var result = execute();

result.ShouldBe(false);
}

[Fact]
public void does_not_detect_order_with_other_description_as_invalid()
{
_order.Description = "other description";

var result = execute();

result.ShouldBe(false);
}
}

Super. Kilkanaście commitów później sklejam wszystko w całość i uruchamiam. Damn, nie działa! Jak to możliwe?


Z kwadrans zajęło mi dojście do źródła problemu…


Co z tego że mam testy, skoro one testują ODWROTNY sposób działania tego “detectora”?

Widzicie? Metoda o nazwie “IsValid” sprawdza, czy zamówienie jest “invalid”. A reszta kodu korzysta z niej zgodnie z nazwą…



Uwaga! Z wielką przyjemnością ogłaszam Inicjatywę SmartTesting.pl i serdecznie Cię na nią zapraszam! Tam wraz z TOP Expertami będziemy dostarczać masę rewelacyjnych materiałów o testach!




SmartTesting - zapisz się!



W napisanym, przetestowanym, zacommitowanym kodzie mam taką głupotę, że aż strach. Moja głowa musiała gdzieś odfrunąć. Mózg się wyłączył, a rency sami klepali testy a potem implementację.


Na szczęście wykryłem ten fakt przed “git push”, więc mogłem poprawić commit żeby nie było wstydu. Co prawda wstyd i tak będzie, bo w końcu jest ten post, ale… chyba warto. Przykład z życia, że jak ktoś się nawet na chwilę zmienia przed komputerem w debiloidiotę, to i TDD nie pomoże.


Odpowiedź zatem jest prosta: nie, TDD nie chroni przed głupotą. TDD nie zwalnia z myślenia. TDD nie zrobi z nas geniuszy.


Happy testing!




SmartTesting - zapisz się!


The post Czy TDD chroni przed głupotą? appeared first on devstyle.pl.

 •  0 comments  •  flag
Share on Twitter
Published on June 08, 2020 02:22
No comments have been added yet.


Maciej Aniserowicz's Blog

Maciej Aniserowicz
Maciej Aniserowicz isn't a Goodreads Author (yet), but they do have a blog, so here are some recent posts imported from their feed.
Follow Maciej Aniserowicz's blog with rss.