Testowanie wysyłki e-mail w ASP.NET MVC

Wprowadzenie

W poprzednich dwóch wpisach (Postal – wysyłka email w ASP.NET MVC oraz Hangfire – wysyłka email w tle) pokazałem, jak wysyłać wiadomości e-mail w aplikacji ASP.NET MVC. Jeśli nie czytałeś/czytałaś tamtych artykułów, to zachęcam do nadrobienia lektury, szczególnie że w tym wpisie będę bazował właśnie na kodzie z poprzednich wpisów. W dzisiejszym poście chciałbym jeszcze pozostać przy tej tematyce i pokażę Ci, w jaki sposób można automatycznie testować kod odpowiedzialny za wysyłkę wiadomości w ASP.NET MVC.

Wysłanie e-mail możemy przetestować na dwa sposoby:

  • Testy jednostkowe – sprawdzamy, czy metoda Send z IEmailService (interface pochodzi z biblioteki Postal) została wywołana z określonymi parametrami
  • Testy integracyjne – możemy skorzystać z testowego serwer SMTP, wysłać fizycznie wiadomość i później sprawdzić w serwerze jej właściwości.

W tym wpisze pokażę oba te sposoby. Zachęcamdo pobrania kodu przykładu z githuba – https://github.com/danielplawgo/PostalAndHangfire

Jest to ten sam przykład, w którym pokazywałem wysyłkę wiadomości za pomocą bibliotek Hangfire oraz Postal. Dodałem do niego projekt z testami.

Zmiany w kodzie

Aby móc automatycznie przetestować (w szczególności za pomocą testów jednostkowych) działanie wysyłania wiadomości e-mail, musiałem zmienić nieco kod w klasie BaseMailer:

W poprzedniej wersji BaseMailer w metodzie Send ręcznie tworzona była instancja klasy EmailService. W tym momencie zdecydowałem się na wprowadzenie nowego elementu, który jest odpowiedzialny za tworzenie EmailService. Dodałem IEmailServiceFactory, aby z jednej strony łatwiej można było testować klasy „*Mailer” za pomocą testów jednostkowych, a z drugiej strony aby logiki tworzenia EmailService nie zamykać w konfiguracji kontenera Autofac.

Sama klasa EmailServiceFactory wygląda tak:

W EmailServiceFactory znajduje się teraz kod odpowiedzialny na konfigurację silnika Razor, aby możliwa była wysyłka wiadomości e-mail bez kontekstu HTTP. W tym kodzie również nastąpiła drobna zmiana, aby można było go testować.

Wcześniejsza implementacja wykorzystywała klasę HostingEnvironment oraz metodę MapPath z tej klasy do mapowania ścieżki w ramach projektu ASP.NET MVC do fizycznej lokalizacji na dysku. Niestety w przypadku uruchamiania testów (dokładnie testów integracyjnych, o których będzie później) ta metoda zwraca błąd, dlatego trzeba ją opakować nowym interfejsem i w przypadku testów wykonać nieco inną logikę. Poniżej kod samego interfejsu oraz dwóch implementacji – jednej wykorzystywanej w aplikacji, drugiej w testach:

Logika w TestHostingEnviromentService zmienia katalog, w którym są wyszukiwane widoki. Podczas wykonywania testów widok szukany byłby w katalogu projektu z testami, gdzie go nie ma. Dlatego w tej implementacji IHostingEnviromentService mapuje katalog na folder właściwej aplikacji ASP.NET MVC, dzięki czemu testy integracyjne będą działać.

Darmowy kurs Visual Studio

Pracując z setkami programistów, zauważyłem, że większość osób nie pracuje efektywnie w Visual Studio. W skrajnych przypadkach korzystali z kopiowania z wykorzystaniem menu Edit. Wiem, że to dziwne, ale naprawdę niektórzy tak pracują. Dlatego postanowiłem stworzyć kurs Visual Studio – aby pomóc koleżankom i kolegom w efektywniejszej pracy.

Przygotowałem 20 lekcji e-mail, w których pokażę Ci, w jaki sposób pracować efektywniej i szybciej w Visual Studio. Poznasz dodatki, bez których nie wyobrażam sobie pracy w tym IDE.

Po więcej informacji zapraszam na dedykowaną stronę kursu: Darmowy Kurs Visual Studio.

Quiz C#

Ostatnio przygotowałem również quiz C#, w którym możesz sprawdzić swoją wiedzę. Podejmiesz wyzwanie?

Testy jednostkowe

Do wykonywania testów jednostkowych oraz integracyjnych wykorzystuję bibliotekę xUnit (https://xunit.github.io/) oraz Moq (https://github.com/Moq/moq4/) do atrap. Do testowej aplikacji dodałem nowy projekt (PostalAndHangfire.Tests), w którym będą znajdowały się wszystkie testy. W normalnej aplikacji można utworzyć oddzielne projekty dla testów jednostkowych oraz integracyjnych.

Testy jednostkowe będą testowały poprawne wywołanie metody Send z IEmailService. W praktyce testować będziemy logikę zamiany danych przychodzących w obiektach domenowych na klasy e-mail. Nie będziemy testowali samej wysyłki wiadomości oraz poprawności wygenerowania treści e-mail – zrobimy to w testach integracyjnych.

Tworząc testy, bardzo często wykorzystuję klasy bazowe do wrzucania wspólnej logiki dla testów – czy to dla testów grup klas (tak jak w tym przypadku, gdzie klasa bazowa będzie dla wszystkich testów klas „*Mailer”), czy dla testów, w których pojedyncza klasa testów zawiera testy jednej metody. W przykładzie klasa BaseUnitTests zawiera konfigurację atrap, która jest taka sama dla wszystkich klas „*Mailer”:

Jak widać, tworzę dwie atrapy, a następnie konfiguruję atrapę IEmailServiceFactory, aby metoda Create zwracała atrapę IEmailService.

Sam test jednostkowy wygląda tak:

Tak jak wspomniałem, w teście jednostkowym sprawdzamy, czy metoda Send z IEmailService została wywołana z odpowiednimi parametrami. W testach wykorzystuję metody Create, które tworzą testowany obiekt z atrapami zależności, aby nie powielać tego kodu w każdym teście.

Testy integracyjne

Testy jednostkowe były dość proste i testowały tylko fragment kodu wysyłki wiadomości e-mail. Testy integracyjne są bardziej rozbudowane i umożliwią przetestowanie całej logiki, w tym i generowanie treści wiadomości.

Do implementacji testów potrzebny będzie nam serwer SMTP, abyśmy mogli sprawdzić, czy wiadomość została wysłana poprawnie. Do tego celu wykorzystuję bibliotekę netDumbster (https://github.com/cmendible/netDumbster), która właśnie tworzy taki serwer w locie i umożliwia łatwe wyciągnięcie informacji o wysłanych wiadomościach.

Po zainstalowaniu biblioteki z nugeta musimy jeszcze w pliku app.config z projektu z testami dodać informacje o serwerze SMTP, który będzie wykorzystywany podczas testów. Robi się to bardzo podobnie, jak w przypadku prawdziwego serwera:

W przypadku netDumbster w app.config podajemy dwie rzeczy: host (localhost) oraz port (np. 25).

W testach jednostkowych również wykorzystuję klasę bazową (BaseIntegrationTests), w której teraz znajdują się pomocnicze metody tworzące tym razem realne zależności dla testowanych klas „*Mailer”:

Sam test integracyjny nie jest dużo bardziej rozbudowany od testu jednostkowego. Dochodzi przede wszystkim uruchomienie testowego serwera SMTP (podajemy w parametrze port z app.config) z biblioteki netDumbster oraz późniejsza seria asertów, które sprawdzają poprawność wysłanej wiadomości e-mail wyciągniętej z testowego serwera SMTP:

W przypadku testowania treści wiadomości osobiście skupiam się na występowaniu poszczególnych fraz (dlatego w przykładzie są dwa aserty). Wiadomości e-mail bardzo często są zbudowane z HTML-a, który z czasem może się zmieniać w zależności od tego, jak chcemy, aby wiadomość wyglądała, sam tekst rzadziej się zmienia. Zauważyłem, że utrzymanie później takiego testu jest bardziej czasochłonne niż gdybyśmy robili asserta dla całej zawartości wiadomości (wraz z kodem HTML). Ale decyzja, który sposób chcesz wykorzystać, należy do Ciebie.

Podsumowanie

Testy automatyczne w naszych aplikacjach są bardzo ważnym elementem utrzymania wysokiej jakości oprogramowania. Dlatego warto testować wszystko  w sposób automatyczny. Mam nadzieję, że już wiesz, w jaki sposób przetestować wysyłkę wiadomości w aplikacji ASP.NET MVC z wykorzystaniem testów jednostkowych oraz integracyjnych (dzięki bibliotece netDumbster).

Zaktualizowany kod przykładu znajdziesz na githubie (https://github.com/danielplawgo/PostalAndHangfire) – zachęcam do pobrania i sprawdzenia w praktyce, jak to wszystko działa.

A Ty testujesz automatycznie wysłanie wiadomości e-mail? Czego używasz?

1 thought on “Testowanie wysyłki e-mail w ASP.NET MVC

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *