Myślę, że Pex jako narzędzie do testowania eksploracyjnego jest naprawdę intrygujące. W tym względzie widzę to jako coś, co chciałbym przekazać QA do użycia.
Jako narzędzie TDD, potrzebuje trochę pracy, ponieważ TDD jest działaniem projektowym. Jednak podoba mi się kierunek, w którym zmierza Peli. Jest coś do powiedzenia na temat projektowania wspomaganego automatycznie. Na przykład, tylko dlatego, że TDD jest narzędziem do projektowania, nie ma powodu, dla którego nie mógłbym mieć automatycznego narzędzia wskazującego potencjalne przypadki brzegowe podczas projektowania, prawda? Buduj jakość od samego początku.
Zobacz ten wpis, w którym Peli używa Pex w przepływie pracy w stylu TDD. http://blog.dotnetwiki.org/TDDingABinaryHeapWithPexPart1.aspx
Co to jest testowanie eksploracyjne w rozumieniu QA? Wygląda na to, że nie jest to tak blisko testowania eksploracyjnego w odniesieniu do ISTQB/ISEB/IEEE/ISO. Czy to nie narzędzie analizuje Twój kod i generuje Przypadki Testowe na podstawie reguł, które zaimplementował w nim? Brzmi bardziej jak system ekspercki niż testowanie eksploracyjne - http://pl.wikipedia.org/wiki/Wyszukiwarka eksploracyjna. – yoosiba
@yoosiba "Zautomatyzowane badania eksploracyjne" to frazeologia prosto z MS (http://channel9.msdn.com/posts/briankel/Pex-Automated-Exploratory-Testing-for-NET/).Wygląda na to, że od tego czasu wycofali się z tej terminologii. –