Page 3 of 9

Korzyści z TDD na systemach embedded

Tworząc systemy embedded musimy zmierzyć się z tymi samymi problemami, co przy tworzeniu innych rodzajów oprogramowania, czyli między innymi:

  • Zmieniającymi się wymaganiami.
  • Zaburzaniem działania istniejących funkcjonalności po wprowadzeniu zmian.
  • Napiętymi terminami.
  • Rosnącym z czasem skomplikowaniem systemu utrudniającym jego utrzymanie i rozszerzanie.

Poza tym istnieje również cała gama dodatkowych problemów, specyficznych dla systemów embedded. Są one związane między innymi z:

  • Potrzebą integracji ze sprzętem.
  • Pisaniem kodu na mikrokontrolery o ograniczonych zasobach
  • Potrzebą spełnienia norm dotyczących niezawodności systemu.
  • Interakcją z zewnętrznymi urządzeniami i pracą w ciężkich warunkach.

W tym wpisie opiszę dokładniej te problemy oraz pokażę jak Test Driven Development może pomóc w ich rozwiązaniu.

Czytaj dalej

Mocki – radzenie sobie z zależnościami w testach

Testowanie kodu, który nie wykorzystuje zewnętrznych zależności jest stosunkowo proste. W większości przypadków testowany moduł współpracuje jednak z innymi elementami systemu.  Stawia to przed testami dwa wyzwania – po pierwsze powinny poprawnie działać, a po drugie sprawdzać poprawność tej współpracy. Nie jest to zadanie proste, a zewnętrzne zależności są jednym z głównych czynników utrudniających testowanie.

Czytaj dalej

Jak optymalizować działanie programu?

Ostatnio w pracy miałem za zadanie dokonać optymalizacji pewnego fragmentu kodu. Postanowiłem, że to dobra okazja, aby zebrać trochę porad dotyczących optymalizacji i się nimi podzielić. Część porad odnosi się konkretnie do C, ale większość można uogólnić na każdy język. Entuzjaści wyciskania procesorów do granic możliwości mogą jednak poczuć się zawiedzeni, ponieważ nie będę się skupiał na trickach urywających pojedyncze takty. Bliżej mi do podejścia przedstawionego w dwóch zasadach optymalizacji:

  1. Nie rób tego.
  2. (Tylko dla ekspertów) Jeszcze tego nie rób.

Czytaj dalej

Postępy prac nad Micromouse

Dawno nic nie było o postępach w pracach nad Micromousem, więc pora na mały update. Od ostatniego wpisu o regulatorze obrotów z sierpnia udało się zrobić parę rzeczy. Udało się również parę rzeczy zepsuć. Projekt posunął się do przodu na różnych frontach, ale postępy przystopowało trochę spalenie płytki.

Czytaj dalej

O elektronice i podstawianiu pułapek

Ostatnio zrobiłem zwarcie na płytce mojego micromouse i teraz będę musiał lutować wszystko od nowa. Podłączyłem zasilanie z programatora do linii danych i prawdopodobnie uszkodziłem procesor. Już któryś raz zdarzyło mi się coś podobnego. Raz nawet udało mi się zewrzeć układ składający się z samych gotowych modułów tak, że wszystkie zniszczyłem. W takich sytuacjach zawsze miałem podejście w stylu – bezmyślnie podłączyłem na odwrót, to się spaliło. Na drugi raz muszę uważać. Otóż nie – spaliło się, bo byłem niechlujny robiąc to złącze. Składało się ono z czterech przewodów, z których każdy był niezależny i można je było wpiąć w dowolnej kolejności. Z góry założyłem, że będę pamiętał, który kolor kabelka gdzie ma pójść, więc nie muszę robić żadnych oznaczeń. Zastawiłem więc pułapkę na samego siebie w przyszłości i to było tylko kwestią czasu, kiedy w nią wpadnę.

Czytaj dalej

Antywzorce unit testów

W ostatnim wpisie przybliżyłem zestaw dobrych praktyk w pisaniu unit testów. Dzisiaj będę kontynuować ten temat z trochę innej perspektywy i opowiem o antywzorcach. Dzięki charakterystycznym nazwom, piętnującym konkretne złe praktyki, antywzorce zostają w pamięci i mamy je przed oczami pisząc podejrzany kod.

Czytaj dalej

Jak pisać dobre unit testy

Często unit testy nie są przez programistów traktowane jak prawdziwy kod. Są dla nich jedynie narzędziem do osiągnięcia określonego celu – sprawdzenia poprawności implementacji. Przez to testy stają się trudne w utrzymaniu albo wykonują się zbyt długo. Przez co uniemożliwiają pracę zgodnie z TDD i nie mają wartości dokumentacyjnej. Istnieją jednak proste zasady tłumaczące, jak powinny wyglądać dobrze napisane testy.

Czytaj dalej

Kiedy nie stosować TDD

W poprzednich częściach cyklu skupiałem się na korzyściach płynących z TDD. Jeżeli ta metoda wejdzie nam w krew, te korzyści zachęcą nas, abyśmy pisali w ten sposób zawsze i wszędzie. Motywują nas do tego również eksperci mówiący, że każda linia kodu powinna być przetestowana. Okazuje się jednak, że nie zawsze testowanie wszystkiego na siłę jest dobrym rozwiązaniem. W tym artykule opiszę sytuacje, kiedy nie opłaca się używać TDD.

Czytaj dalej

Wymówki, aby nie pisać unit testów

Próbując wprowadzić TDD w projekcie najczęściej spotkamy się z oporem. Argumenty przeciwko tej technice ze strony developerów i osób decyzyjnych, które nie miały z nią do czynienia często się powtarzają. Postanowiłem więc w tym wpisie zebrać te argumenty i je omówić. Krytyka TDD ze strony osób mających doświadczenie w temacie zwykle przybiera inną formę i jest to temat na osobny wpis.

Czytaj dalej

Zalety TDD

Przestawienie się na Test Driven Development z pisania metodą tradycyjną nie jest łatwym zadaniem. Szczególnie na początku musimy walczyć ze starymi nawykami, a kiedy napotykamy trudności, naturalnym rozwiązaniem jest stosowanie metod, które znamy i rozumiemy. Poza tym początkowo TDD może nam się wydawać nieintuicyjne, a wkład pracy wydaje się większy. Jak to zwykle bywa w takich przypadkach, kluczem jest wytrwałość. Każda umiejętność wymaga czasu, aby ją dobrze opanować. Kiedy już nam się to uda, zauważymy, że praca w ten sposób przynosi nam pewne wymierne korzyści. W tym wpisie postaram się owe korzyści przybliżyć.

Czytaj dalej

© 2018 ucgosu.pl

Theme by Anders NorénUp ↑