Podróż

5 minutes

Wstęp

Podróż czas zacząć. Długo wahałem się czy wystartować w konkursie „Daj się poznać”, ponieważ zdawałem sobie sprawę ile czasu będę musiał poświęcić na napisanie aplikacji i prowadzenie bloga, a że jestem ambitny to chcę upiec dwie pieczenie na jednym ogniu i piszę bloga w dwóch językach. Wersja polska i angielska nie będą wiernymi tłumaczeniami, a raczej bliźniakami, którzy są podobni, ale nie identyczni. Kolejnym wyzwaniem jest technologia, którą wybrałem Asp.Net Core, a w której jeszcze nic nie napisałem to wszystko sprawia, że aplikacja nie będzie produktem, a raczej „proof of technology”, nie będzie optymalizacji do perfekcji każdej metody czy klasy, a raczej spojrzenie na problem i pokazanie jednego z rozwiązań niekoniecznie optymalnego. To sprawia, że czas, który bym musiał poświęcić na optymalizację, mogę przeznaczyć na badania różnych technologii. Po tym krótkim wstępie przejdźmy do samego projektu.

Projekt

Projekt Optimal Word Learning (OWL) ma pomóc w zrozumieniu tekstów książek, artykułów i instrukcji obsługi napisanych w języku angielskim.

Wyjaśnię w skrócie zasady działania aplikacji. Tworzy ona listę słówek. Wykorzystujemy następnie zasadę, że przy znajomości słownictwa w danym tekście na poziomie 70%, poziom jego zrozumienia kształtuje się na poziomie 90%. Podchodząc w ten sposób do każdego nowego tekstu, możemy osiągnąć poziom jego zrozumienia na 90%, ucząc się zaledwie 70% słówek. Daje to olbrzymią oszczędność czasu i energii. Więcej o zaletach tego projektu tutaj.

Aplikacja zostanie napisana w technologii ASP.Net Core w języku C#. Relacyjna baza danych będzie „dowolna”, dzięki zastosowaniu wzorca repozytorium (o tym w kolejnych wpisach). W skład solucji wejdą projekty:
  • Owl.Library,
  • Owl.Library.UnitTests,
  • Owl.Mvc,
  • Owl.Mvc.UnitTests.
Do testów jednostkowych wybrałem framework xUnit. Dlaczego xUnit? Bo go nie znam, a chcę poznać. Wybrałem z pośród frameworków: NUnit, MStest, XUnit. Pełny zestaw testów jednostkowych mamy tu. A więc zaczynamy pisanie aplikacji. Otwieramy Visual studio 2017 i tworzymy solucję, a następnie 4 projekty. Solution Explorer VS2017

Po utworzeniu dodajemy referencje testów do odpowiednich projektów. (TooExe.Owl.Library.UnitTests => TooExe.Owl.Library) i (TooExe.Owl.Mvc => TooExe.Owl.Mvc.UnitTests)

AddReference VS2 2017

Reference Manager VS 2017

 

Poniżej widzimy, że referencje zostały dodane.

Solution Explorer VS 2017 Dependencies

Gdy już mamy przygotowaną solucję z projektami możemy zacząć pisać pierwszą funkcjonalność. Aplikacja będzie pisana techniką TDD (Test-Driven Development ). Napisano już wiele na ten temat Ja postaram się zminimalizować teorię i pokazać na przykładzie aplikacji Owl jak to działa.

Czym jest TDD? TDD jest techniką programowania tzn. technika pisania i budowania kodu. Cele:
  1. Napisanie testu przed implementacją kodu wymusza przemyślenie designu w naszym projekcie. Klasa w teście jednostkowym powinna być odizolowana od innych klas. Programista musi zatem zidentyfikować te miejsca, gdzie zależności (ang. shims) występują i zaprojektować klasy z ich uwzględnieniem. TDD wymusza dobry design poprzez rozpoznanie interakcji i interfejsów między klasami. Uzyskujemy dzięki temu klasy luźno związane ze sobą (ang. loosely coupled).

  2. Testy muszą dokumentować naszą aplikację. Dzięki temu, testujemy i implementujemy kod, który spełnia wymagania klienta. Rozważając testy pod kątem wymagań musimy zdefiniować punkty brzegowe każdego kryterium, np. powtarzalność wyrazów, plik bez danych lub wyjątki w rzeczownikach (liczba mnoga i pojedyncza).

  3. W TDD nie piszemy testów i nie implementujemy kodu do rzeczy, których nie potrzebujemy teraz.
  Kluczowym aspektem TDD jest cykl pisania testów. Najpierw piszemy testy, następnie implementujemy funkcjonalność, a na końcu refaktoruzyjemy.
    1. Red: Piszemy test, który się nie powiedzie. Testy piszemy do pustych, ale istniejących już klas i metod (dzięki czemu możemy korzystać z IntelliSense). Uruchamiamy test i oczekujemy, że się nie powiedzie.
    2. Green: Piszemy kod aby testy się powiodły.Implementujemy kod (według dokumentacji).Uruchamiamy testy. Wszystkie testy muszą się powieść.
    3. Refactor: Wprowadzamy zmiany, które poprawiają jakość kodu (np. usunięcie zduplikowanych linii kodu), ale nie zmieniają jego funkcjonalności. Po refaktoryzacji, uruchamiamy wszystkie testy by sprawdzić czy czegoś nie zepsuliśmy.
TDD Nie będę omawiał zalet i wad takiego podejścia. Moim zdaniem warto.