Hi! First of all I’d like to ask you a question – what’s your name? My name is Piotr and that is derived from the Greek Πετρος (Petros) meaning “stone”.  Next to me is sitting my friend – Michael. Michael is from the Hebrew name מִיכָאֵל (Mikha’el) meaning “who is like God?” (after this article […]

The post ClassManager – You shall not pass appeared first on Piotr Pasich.

Three days ago I decided to give you some motivation to start doing a code kata (see the Friday Dopamine Dump). Well, if you forgotten, haven’t got any time, had to do something more important and didn’t even try to try, then stop. No excuses! If you really want to do this – just start. […]

The post It’s Monday, you could use some motivation appeared first on Piotr Pasich.

When we were in Madrid last year, a book was accompanied me – the new edition of Clean Code authored by Uncle Bob. He describes how the professional programmer acts, works, talks and develops himself. Robert C. Martin claims an example from his own life – a quick, 15 minutes, code kata done twice a […]

The post Friday Dopamine Dump appeared first on Piotr Pasich.

This topic’s stayed in my mind for a while. Inspired by Joshua Thijssen’s presentation from PHP UK about (re)discovering the SPL in PHP, I decided to investigate this more carefully. I have to admit that took me some time to understand how the things work and how to not misunderstood the purposes of each iterator […]

The post SPL Iterators against the performance appeared first on Piotr Pasich.

A few weeks ago i have introduced nice CRUD generator for generating basic admin scaffold. Today I have something even more interesting: Easy Symfony2 Admin panel generator. According to the documentation we should be able to generate complete and good looking admin panel in about 30 seconds (not including the installation and configuration). I decided to give this bundle a shot.

Post Symfony2 Admin panel in 30 seconds? pojawił się poraz pierwszy w Kamil Adryjanek.

Na wstępie: fajnie by było, abyś wiedział mniej więcej co to jest Mock, Stub i Fake - nie będę tego jakoś szczególnie objaśniał bo idea tego wpisu jest inna niż wstęp do "zaślepek". Tutaj możesz poczytać o różnych zaślepkach na przykładzie PHPUnit.

Spis treści, a jak!

1. Wstępniak
2. Kiedy Mock?
   1. Przykład zaślepiania metody typu Query
      1. Zaślepienie metody Query za pomocą Mocka
      2. Zaślepienie metody Query za pomocą Stuba
      3. Zaślepienie metody Query za pomocą Fake
      4. Przemyślenia na temat zaślepiania metod typu Query
   2. Przykład zaślepiania metody typu Command
      1. Zaślepienie metody Command za pomocą Stuba
      2. Zaślepienie metody Command za pomocą Mocka
      3. Zaślepienie metody Command za pomocą Fake
      4. Przemyślenia na temat zaślepiania metod typu Command
3. Końcowe przemyślenia

Wstępniak do góry

Dla przypomnienia, zaślepka (z ang. Test Double) to obiekt, który jest przekazywany do obiektu testowanego zamiast obiektu będącego rzeczywistą zależnością w kodzie produkcyjnym. Przykładem może być wstrzyknięcie zaślepki obiektu ProductRepository (abstrakcji na persystentną kolekcję produktów) do jakieś usługi, np. ProductService.

Aby utworzyć obiekt ProductService potrzeba ProductRepository, aby utworzyć ProductRepository musimy utworzyć EntityManagera (zakładam implementację opartą na Doctrine), aby utworzyć EntityManagera trzeba utworzyć konfigurację oraz połączenie z bazą danych, aby połaczyć się z bazą danych musimy mieć z czym się połaczyć, więc serwer bazy danych musi być zainstalowany, schema bazy powinno być utworzone itp. Aby utworzyć obiekt konfiguracji, trzeba utworzyć obiekt cache... Na litość Boską, ja tylko chcę przetestować czy ProductService::createProduct($name, $price) tworzy obiekt produktu, zapisuje go w repozytorium i triggeruje przy tym odpowiedni event...

Powyższa historyjka pokazuje jedną z przyczyn stosowania zaślepek. Jest ich więcej, np:

• Uproszczenie setUp testu
• Testy w izolacji (tzw. testy jednostkowe), nie chcemy drugi raz testować DoctrineProductRepository - ta klasa ma osobne testy!
• Zwiększenie szybkości wykonywania testów - zewnętrzny web service zastępujemy lokalnym Stubem/Fake, repozytorium operujące na bazie zastępujemy implementacją in memory
• Możemy w prosty sposób przetestować sytuacje brzegowe, które ciężko zreprodukować wykorzystując rzeczywisty obiekt
• Podczas pisania implementacji klasy X, która zależy od typu Y, nie mamy jeszcze implementacji Y

Oczywiście są sytuacje, w których nie należy stosować zaślepek. Należy pamiętać, że nie należy zamieniać części obiektu/podsystemu który testujemy. Np. nie powinno się zastępować EntityManagera implementacją "in memory" w testach DoctrineProductRepository, gdyż testy te mają testować, czy poprawnie szukamy / zapisujemy dane w bazie.

Kiedy Mock? do góry

W idealnym świecie, zgodnie z zasadą Command-Query separation, każda metoda powinna być typu Command lub Query.

• Command - zmienia stan obiektu/systemu nie zwracając żadnej wartości - najprostszy przykład to setter ;)
• Query - pobranie stanu obiektu/systemu nie zmieniając stanu - najprostszy przykład to getter

W złym guście jest tworzenie metod które zarówno są Command i Query, bo taka funkcja robi de facto dwie rzeczy - zmienia stan i go zwraca. Nie można wywołać 2x taką metodę aby pobrać stan, gdyż za każdym wywołaniem ten stan jest zmieniany.

Związek typu metod z zaślepkami:

1. Mocki można stosować do zaślepiania metod typu Command, ale nie powinno się stosować do zaślepiania metod typu Query (są wyjątki)
2. Stuby można stosować do zaślepiania metod typu Query, ale nie należy stosować do zaślepiania metod typu Command
3. Fake można stosować do zaślepiania metod typu Query i Command

Krótkie wyjaśnienie aby nie było zamętu:

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...