Wspominałem niedawno, że w pracy nie trzeba robić wszystkiego szablonowo. Można się postarać i uczyć, rozwijać siebie i innych. Nieważna jest firma, korporacja w której pracujesz. Nieważne jest stanowisko, które zajmujesz. Ważne jest tylko czy chcesz. Dziś opiszę jak testować aplikację C# za pomocą F#. Po co to robić? To jeden z powodów. A właściwie 10 (i więcej). A oprócz tego dla przyjemności i rozwoju. Nauczenia się czegoś nowego w pracy zamiast po pracy...
Sztuka programowania 3158 dni, 8 godzin, 4 minuty temu 157 źrodło rozwiń
Wiadomo, że każdy projekcie są testy. W części z nich są testy jednostkowe, w innych są testy integracyjne, w innych testy programistyczne - programista klika i jak działa to działa, a w jeszcze innych test na produkcji u klienta razem z milionami użytkowników. Generalnie każdy jakieś test ma. Wiadomo jak jest w projektach komercyjnych, klient chce aplikację działająca, wykonaną z najnowszymi i najlepszymi technikami, najlepiej napisaną przez juniorów, bez testerów i PM...
Sztuka programowania 3523 dni, 19 godzin, 31 minut temu 284 źrodło rozwiń
Definicja testów jednostkowych nie jest jednoznaczna i moim zdaniem zmieniała się przez lata. Jednostkę (“unit”) można w różny sposób interpretować. Wiele programistów uważa, że należy testować wyłącznie poszczególne klasy. Dobrą stroną takiego podejścia jest fakt, że jak test zakończy się niepowodzeniem, wtedy od razu wiadomo gdzie szukać przyczyny. Przy dobrym zestawie testów, debugger przestaje być potrzebny. Osobiście preferuje zupełnie inne podejście. W aplikacjach biznesowych, moim zdaniem aż t...
Sztuka programowania 3593 dni, 6 godzin, 45 minut temu 263 źrodło rozwiń
Witam w ostatnim wpisie z serii „Testowanie z Jasmine„, w którym to zajmę się, zgodnie z tytułem, zagadnieniem testowania operacji asynchronicznych – zresztą w komentarzach pod jednym z wpisów serii, prosił o to jeden z czytelników bloga, a ja obiecałem, że to zrobię więc, tym bardziej czuję się w obowiązku aby ten temat zgłębić i go Wam tutaj jak najlepiej przedstawić Tematyka ta wbrew pozorom nie jest szczególnie skomplikowana… No nic, jak zwykle nie ma co...
Witam w kolejnym już wpisie z serii „Testowanie z Jasmine”. Tak jak obiecałem ostatnio, tym razem zajmiemy się bardzo przydatnym elementem frameworka Jasmine, a konkretnie tytułowymi szpiegami (ang. spy – w dalszej części wpisu będę posługiwał się zamiennie terminem polskim i angielskim). Generalnie, jak sama nazwa wskazuje, taki szpieg służy do szpiegowania… A konkretniej szpiegowania wywołań funkcji oraz przekazywanych do niej argumentów. Zobaczmy z czym t...
Witam ponownie! Dziś, tak jak zapowiadałem w ostatnim wpisie, znów powraca temat „Testowanie z Jasmine” Powoli robi się z tego taki mini kurs (czy jak to nazwać) no ale temat zdecydowanie wymaga kontynuowania… Zatem dziś kolejne aspekty frameworka Jasmine, a konkretniej matchery czyli odpowiedniki asercji znanych z innych frameworków testowych; ponadto „setup” oraz „teardown” czyli sposób na inicjowanie testów i sprzątanie po nich; wspomnę także o metodach w...
W poprzednim wpisie na temat testowania kodu JavaScript, przedstawiłem trzy najpopularniejsze frameworki służące do tego celu – QUnit, Mocha oraz Jasmine. Napisałem też baaardzo pokrótce na czym generalnie polega testowanie JavaScript. Myślę jednak, że to zdecydowanie za mało… Postanowiłem więc trochę zgłębić temat na łamach bloga, tak żebyśmy wszyscy się mogli czegoś nowego nauczyć Całkiem subiektywnie, na warsztat wybrałem Jasmine. Podoba mi się składnia ...
Sometimes when you write tests you want to check how the code behaves in different cases. I had already experienced that a couple of times before and I always used TestCase annotation available in nUnit library. It’s nice to know that nUnit offers an alternative approach as well...
Był taki smutny czas, że struktura dziedziczenia w moich testach zdecydowanie przerastała stopniem skomplikowania dziedziczenie w testowanym kodzie. A bo jedna klasa bazowa dla testów umożliwiała na przykład kontakt z prawdziwą bazą. Inna – testy z bazą in-memory. Jeszcze inna – puszczanie requestów do systemu. I tak dalej. Efekt był taki, że de facto wszystkie testy dziedziczyły ze wszystkiego. Fuj na maxa, z pryszczem jeszcze ohydnym....
Sztuka programowania 4008 dni, 5 godzin, 20 minut temu 164 źrodło rozwiń
Pisząc testy jednostkowe dość często spodziewamy się identycznego zachowania w różnych testowanych scenariuszach. “Gdy zajdzie X, ma wydarzyć się A, B i C”. Z kolei “gdy zajdzie Y, ma wydarzyć się A, B i D”. W takich przypadkach, wykorzystując standardowe biblioteki do unit testów, mamy do wyboru kilka rozwiązań: wspólna klasa bazowa współdzielone metody “asercji” w ramach jednej klasy copy/paste testów pomiędzy klasami … pewnie jeszcze coś i...
Sztuka programowania 4235 dni, 7 godzin, 35 minut temu 102 źrodło rozwiń
This post is secod part of my Back to basics: on testing series.Developers writing tests People new to software, or coming from organizations where all testing is done by dedicated people often find the idea of developers doing testing bizarre. After all, we're the highly trained, educated professionals. We get payed to do the hard bits. Clicking around the UI to see if a label is misaligned or an app crashed surely ...
Sztuka programowania 4338 dni, 7 godzin, 48 minut temu 61 źrodło rozwiń
Programując pod Sharepointa czy inne tego typu badziewie musimy podpisywać nasze assemblies i wrzucać je do GACa. Już dwa razy mnie to "ugryzło" i straciłem w sumie dobre kilka godzin na diagnostykę poniższego scenariusza: 1) piszę testy do funkcjonalności zawartej w podpisanej dllce 2) koduję implementację w tejże dllce 3) uruchamiam testy 4) dostaję wyjątek TypeLoadException czy coś innego w ten deseń mówiącego, że w testowanej dllce nie ma kodu który... przecież tam jest bo dopiero co go napisałem!
Jak każdemu porządnemu developerowi zdarza mi się czasem napisać testy. Jak każdemu porządnemu developerowi, czasem zdarza mi się wykorzystać mechanizm metod rozszerzających (jeśli nie wiesz o czym mówię sprawdź na msdn). Jak każdy prawdziwy developer, chciałem przetestować logikę, która była wykorzystywana w jednej z takich metod. W zasadzie to nie w samej metodzie, chciałem sprawdzić czy zostanie wywołana z wartościami, które są dla mnie ważne. Zacznę od metod rozszerzających, a testowanie przyjdzie ...
Sztuka programowania 4539 dni, 15 godzin, 58 minut temu 207 źrodło rozwiń
Na dzień dzisiejszy wybierając "mocking framework" stawiam właśnie na fakeiteasy. Ma ona jeden ciemny zakamar, w którym można nieźle pobłądzić... a jest to testowanie wywołania settera.
Niedawno po raz pierwszy w życiu musiałem mockować implementację interfejsu IEnumerable<T>. Chodziło o jakieś dziwne struktury używane wewnętrznie przez FIM. Problem polegał na tym, że obiekt mockowanego przeze mnie typu zwracał kolekcję innych obiektów. Ta kolekcja była właśnie IEnumerable<X>... ale nie mogłem stworzyć jej instancji, ponieważ wspomniana klasa XCollection była abstrakcyjna, a jej implementacja siedziała zaszyta gdzieś wewnątrz jakichś dllek. Jednocześnie chciałem przetestować...
Odpowiedź na pytanie postawione w tytule pytanie to temat nie na posta, ale na całą (może nawet niejedną) książkę. Poniżej postaram się nakreślić najważniejsze według mnie aspekty tworzenia testów... chociaż na pewno lista ta nie jest kompletna. Aha, no i nie jestem w stanie podać niezawodnej recepty na "dobry test". Zgłębiam temat od dobrych kilku lat i sam ciągle się uczę, więc cudów nie ma - praktyka i identyfikowanie własnych pomyłek jest najlepszym nauczycielem:).
W komentarzach do ostatniego posta wywiązała się dyskusja na temat "a co z metodami prywatnymi?". Odpowiedź najkrótsza z możliwych brzmi: NIC. Zainteresowanych odsyłam do tamtejszych wypowiedzi, a w niniejszej notce postaram się zawarte tam myśli rozwinąć. Zaczynając przygodę z testami jednostkowymi często stawałem przed dylematem "jak mam przetestować funkcjonalność z metod prywatnych?". Sporo się naszukałem i naczytałem o różnych rozwiązaniach, z czego dwa zdawały się być najpopularniejsze i najbardzi...
Na tak postawione pytanie aż chciałoby się odpowiedzieć: "testować wszystko, you fool!". Życie uczy jednak, że takie podejście jest bardzo niepraktyczne i na dłuższą metę nie ma sensu. Dążenie do pokrycia 100% kodu mija się z celem i jest po prostu stratą czasu. O powodach pisania testów pisałem na początku tego cyklu. Są jednak miejsca, w których koszt napisania testu jest bardzo duży, a jego wartość - znikoma. Zacznijmy więc od odpowiedzi na trudniejsze pytanie. Czego nie testować?
Autor: [ten post jest częścią mojego minicyklu o testach, pełna lista postów: tutaj] Po dość długiej przerwie wracam do tematu testów jednostkowych. Kombek zainicjuję krótkim zahaczeniem o mocki, które opisałem w poprzednim poście cyklu. Poruszyć chcę dzisiaj dwie kwestie. Kwestia 1: terminologia Niedawno na blogu Piotra Zielińskiego pojawił się post opisujący różnice pomiędzy terminami określającymi to co ja rozumiem przez "mock". Przypomniało mi to czasy, gdy starałem się zgłębiać definicje skrywając...
Architektura 4766 dni, 6 godzin, 56 minut temu 186 źrodło rozwiń
Dzisiaj chciałbym przedstawić działanie narzędzia do mockowania Telerik JustMock. Dostępne są dwie wersje tego narzędzia: darmowa JustMock Free Edition oraz komercyjna, pełne porównanie można znaleźć tutaj: http://www.telerik.com/products/mocking/free.aspx. Główną motywacją do napisania tego postu było to, że czytając posta Macieja Aniserowicza (oczywiście polecam Macieja serię postów o testowaniu: http://www.maciejaniserowicz.com/post/2011/08/08/UT-0-Zapowiedz-minicyklu-o-testach.aspx) zauważyłem w kome...