2011-05-26 18 views
7

Biorąc pod uwagę poniższy przykładowy kod, jak skonfigurować PEX do przestrzegania moich umów Code?Jak skonfigurować Pex, aby przestrzegać umów dotyczących kodu?

public static IEnumerable<User> Administrators(this UserGroup userGroup) 
    { 
     Contract.Requires(userGroup != null); 
     Contract.Requires(userGroup.UserList != null); 

     return userGroup.UserList.Where(ul => ul.IsAdmin == true); 
    } 

Obecny problem: Kiedy uruchamiam Pex, nadal generuje przypadki testowe, które naruszają określone umowy kodowe.

FYI: Here are the 'Code Contracts' settings w moim pliku csproj.


EDIT: Czy coś break in SP1?

+0

Czy próbowałeś wysłać je e-mailem? [email protected] – porges

+2

Myślę, że to błąd. Rozwiązanie Johna Nicholasa działa, ale nadal nie jest prawidłowe zachowanie dla PEX. Punktem stosowania kontraktów kodu z pexem było to, że PEX automatycznie wziął pod uwagę umowy kodowe i traktował ich awarię jako oczekiwane zachowanie lub test pozytywny. –

Odpowiedz

4

Najpierw trzeba użyć wersji wpisane z Wymaga

użytkowania ArgumentNullException jak T

Również w projekcji właściwości trzeba powiedzieć cotracts kodu użyć standardowego rewriter. Nie klikaj dochodzić na niepowodzenie;)

Contract.Requires<ArgumentNullException>(i != null); 

następnie kod wygeneruje argumetn wyjątku null i PEX można dodać atrybut do pexmethod powiedzieć, że jest to dozwolone, aby rzucić go i stworzy test mimochodem, że rzuca wyjątkiem

można następnie promować te i zapisać jednostkę testuje

+0

+1: Wielkie dzięki! To ustawienie "Assert on Failure" wywołało duże zainteresowanie. –

+1

Tak, spędziłem kilka godzin rozbijając twarzą w klawiaturę;) –

+0

Myślę, że to raczej rozwiązanie, a nie rozwiązanie. Myślę, że to rozwiązanie może nie wykryć prawdziwego "ArgumentNullException", który może zostać wyrzucony z innego miejsca w testowanym kodzie. Proponuję alternatywne rozwiązanie, które nie ma tego problemu w mojej odpowiedzi. – lexicalscope

3

Naruszenie umów mających na celu sprawdzenie, czy wyjątek został zgłoszony w przypadku naruszenia umowy. Wiele osób skompiluje metody Required w wersji Release, gdzie niektórzy twierdzą, że nadal należy postępować z przypadkami skrajnymi. Możliwe jest również napisanie niestandardowego programu obsługi niepowodzenia umowy, który może nie spowodować wyjątku lub błędu asercji. Jeśli masz niestandardową procedurę obsługi kontraktu, która nie zapobiega dalszemu wykonaniu, możesz spowodować jeszcze większe problemy w dalszej kolejności.

Co Pex robi, to pisać testy, które naruszają umowę tak, że przechodzi, gdy zostanie zgłoszony wyjątek.

TL/DR Nie powinieneś się o to martwić.

+0

Dzięki za informację, Bryan. Ciekawe jednak - czy jest jakiś sposób, aby powiedzieć Peksowi, że może oczekiwać wyjątku i zaznaczyć ten zielony test, gdy narusza on umowę? –

+0

Pex powinien oznaczyć zielony test, gdy automatycznie narusza umowę, jeśli kontrakt zgłasza twierdzenie lub wyjątek. –

+0

Powinno, ale myślę, że obecna implementacja jest zepsuta. Obecnie mam z tym problem. http://stackoverflow.com/questions/5845610/contract-requires-throwing-pex-errors –

1

miałem ten sam problem. Są dwie rzeczy:

1) Sprawdź, Run-time przepisywanie jest włączony (jak sugeruje John)

2) Upewnij się, że twoja klasa test jest ozdobiony [PexClass (typeof (MojaKlasa))]

Test napisałem ręcznie, więc zapomniałem, że atrybut PexClass i kontrakty były traktowane jako regularne wyjątki przez Pex - więc zawodziły.

Honza

1

miałem też włączyć Contract Reference Assembly do Build (ja też emitowanego pliku XML doc tak widzę kontrakty w VS).

Wydaje się to konieczne, aby Pex zrozumiał umowy.

0

Istnieje atrybut PexAllowedContractRequiresFailure, w którym można udekorować metodę testowania, aby Pex nie mógł generować testów powodujących niepowodzenie.

Należy również włączyć opcję "Wykonywanie sprawdzania kontraktu wykonawczego" we właściwościach rozwiązania.

[TestClass] 
public partial class MyTest 
{ 
    [PexMethod] 
    [PexAllowedContractRequiresFailure] 
    public void TestMethod(int myParam) 
    { 
     Contract.Requires(myParam > 5); 
     ... 
    } 
} 

Jest też związany PexAllowedContractRequiresFailureAtTypeUnderTestSurface które myślę, że może być pomocne, jeśli „wymaga” że chcesz Pex szanować są głębiej w drzewie połączeń.