Testy Konwencji – Maciej Aniserowicz – Notatka z nauki

Zanotowałem z tego materiału:

• Testy konwencji to testy sprawdzające, czy pisany kod jest zgodny z założonymi standardami (w tym nazwy zmiennych, formatowanie, struktura katalogów, niepowtarzania błędów – np. wołanie Dispose). Powinny być zrobione tak, aby działały podczas pisania kodu, a nie były wykonywane dopiero na serwerze budującym po scommitowaniu kodu.
• Testy konwencji pozwalają:
  • Zapewnić, że wszyscy piszą kod w tym samym stylu (np. nazwy interfejsów zaczynają się od I, nazwy kontrolerów kończą się słowem Controller).
  • Struktura folderów i klas jest odpowiednia.
  • Klasy danego typu muszą implementować interfejs.
  • Nie powtarzać błędów.
  • Wszystkie testy są publiczne (niepubliczny test nie będzie odpalany).
  • Sprawdzanie sortowanie usingów.
  • Sprawdzanie, czy są użyte tabulatory, czy spacje.
  • Czy np. słowo Go nie jest użyte w skryptach sql.
  • Sprawdzenie ustawień plików, np. są Embeded Resource.
  • Sprawdzić, czy każdy interfejs ma przynajmniej jedną implementację.
  • Sprawdzenie, że każda komenda ma tylko jednego Handlera (CQRS).
  • Sprawdzenie zbędnych komentarzy.
  • Wykrywanie literówek.
  • Używanie czasu w strefie czasowej UTC.
• W testach sprawdzaj, czy nie operujesz na pustych kolekcjach, bo możesz zrobić zły test, np. sprawdzasz, czy wszystkie nazwy interfejsów zaczynają się od I, a Twoje wyciąganie wszystkich interfejsów zwraca pustą listę. 
• Testy konwencji pozwalają budować system pilnujący nas przed popełnianiem kolejnych błędów oraz reguł dobrego programowania (również specyficznych dla naszego oprogramowania i naszego podejścia). Testy konwencji testują naszą architekturę w kontekście naszych decyzji architektonicznych.