Testy mniej i bardziej jednostkowe

Przez ostatnie trzy miesiące opisywałem jak działa DSLExecutor. A jeszcze ani razu nie napisałem skąd wiem, że działa poprawnie. Jako że koniec konkursu zbliża się wielkimi krokami, pora wreszcie poruszyć ten temat. Dlatego dzisiaj opiszę, jak testuję moduły DSLExecutora.

Na początek lista bibliotek, których używam do pisania testów:

• xUnit – framework testów jednostkowych,
• Fluent Assertions – biblioteka pozwalająca wygodnie pisać czytelne asercje,
• NSubstitute – biblioteka umożliwiająca zgrabne tworzenie mocków.

Kod testów umieszczam w projekcie sąsiadującym z projektem zawierającym kod testowany. Projekt testujący nazywam zgodnie z szablonem: [nazwa projektu testowanego].Tests. Zazwyczaj tworzę jedną klasę testującą dla pojedynczej klasy testowanej. Klasy testujące umieszczam w przestrzeniach nazw analogicznych do tych, w których znajdują się klasy testowane.

Wyróżniam dwa rodzaje klas testujących:

• Klasy testujące pojedyncze klasy testowane – takie klasy zawierają typowe testy jednostkowe, w których używam mocków.
• Klasy testujące całe moduły – w nich nie używam mocków, a drzewa zależności buduję takie, jakich spodziewam się podczas rzeczywistego działania aplikacji. Takie testy tworzę dla głównych klas w projektach lub przestrzeniach nazw. Pozwalają one upewnić się, że cały moduł działa prawidłowo.

Przyjrzyjmy się bliżej obu rodzajom testów.

Testy pojedynczych klas

Jak już wspominałem, w klasach implementujących operacje umieszczam po jednej metodzie publicznej. Konsekwencją tej praktyki jest to, że w klasach je testujących wszystkie testy dotyczą pojedynczej metody. Dzięki temu kod testujący daną operację nie miesza się z kodem testującym inną.

Jako że wszystkie testy w klasie testującej testują tą samą metodę, ich kroki Act są takie same. Aby zredukować duplikację, wydzielam ten krok do osobnej metody. Przykład dla klasy testującej klasę ExpressionExecutor, czyli ExpressionExecutorTests:

 
object Act(IExpression expression, 
           IConstantExpressionExecutor cee = null, 
           IFunctionExpressionExecutor fee = null, 
           IBatchExpressionExecutor bee = null) 
{ 
  var ee = new ExpressionExecutor(cee, fee, bee); 
   
  return ee.Execute(expression); 
} 

Przypadki testowe staram się nazywać opisowo (ale zwięźle) – w nazwie metody testującej umieszczam opis warunków początkowych i opis spodziewanego wyniku. W nazwach tych metod stosuję notację snake case, a pomiędzy opis warunków początkowych i opis wyników wstawiam trzy podkreślenia.

Dane wejściowe testu zazwyczaj podaję w atrybutach InlineData (więcej tutaj). Przykładowy test (sprawdzający, czy ExpressionExecutor w celu wykonania wyrażenia reprezentującego funkcję używa zależności FunctionExpressionExecutor) wygląda tak:

 
[Theory] 
[InlineData(0)] 
[InlineData(1)] 
[InlineData(5)] 
void FunctionExpression___invokes_functionExpressionExecutor(
  int expResult) 
{ 
  var exp = new FunctionExpression<Func, int>(); 
  
  var fee = Substitute.For<IFunctionExpressionExecutor>(); 
  fee.Execute(exp).Returns(expResult); 
  
  var result = Act(exp, fee: fee); 
    
  result.Should().Be(expResult); 
} 

Testy modułów

Klasy testujące moduły są bardzo podobne do klas zawierających testy jednostkowe. Różnią się właściwie tylko tym, że nie stosuję w nich mocków. O takie testy aż prosi się klasa DSLExecutor, czyli punkt wejścia do mojego narzędzia. Przykładowo, test dowodzący, że DSLExecutor poprawnie wykonuje wyrażenia reprezentujące wartości stałe, wygląda tak:

 
[Theory] 
[InlineData(0)] 
[InlineData(1)] 
[InlineData(5)] 
void executes_constant_expression(int value) 
{ 
  var exp = new ConstantExpression<int> { Value = value }; 
  var dslExecutor = new DSLExecutor(null); 
  
  var result = dslExecutor.ExecuteExpression(exp); 
  
  result.Should().Be(value); 
} 

(Klasa DSLExecutor nie przyjmuje zależności przez konstruktor – sama sobie tworzy ich instancje.)

Tyle w temacie testów automatycznych. W kolejnym wpisie zaprezentuję wisienkę na torcie, czyli aplikację demonstrującą możliwości DSLExecutora – zapraszam!