Zaawansowane wyszukiwanie
  Strona Główna » Sklep » Algorytmy Wzorce UML » Techniki programowania » Moje Konto  |  Zawartość Koszyka  |  Do Kasy   
 Wybierz kategorię
Algorytmy Wzorce UML
  Algorytmy
  Deep Learning Uczenie maszynowe
  Inżynieria oprogramowania
  Scrum
  Sztuczna inteligencja
  Techniki programowania
  Wyrażenia regularne
  Wzorce projektowe
  Zarządzanie projektami
Bazy danych
Bezpieczeństwo
Bioinformatyka
Biznes Ekonomia Firma
Chemia
DTP Design
E-biznes
Ekonometria
Elektronika Elektrotechnika
Energetyka
Fizyka
GIS
Grafika użytkowa
Hardware
Informatyczne systemy zarządzania
Informatyka w szkole
Języki programowania
Matematyka
Multimedia
Obsługa komputera
Office
Poradniki
Programowanie gier
Programy inżynierskie
Programy matematyczne
Słowniki
Serwery
Sieci komputerowe
Systemy operacyjne
Technika
Telekomunikacja
Tworzenie stron WWW

Zobacz pełny katalog »
 Wydawnictwo:
 MsPress
Crabby Office Lady biurowa szkoła przetrwania

Crabby Office Lady biurowa szkoła przetrwania

44.10zł
37.49zł
BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji 77.00zł 57.75zł
BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji

Tytuł: BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji
Tytuł oryginalny BDD in Action: Behavior-driven development for the whole software lifecycle
Autor: John Ferguson Smart
ISBN: 978-83-283-1747-5
Ilość stron: 408
Data wydania: 02/2016
Oprawa: Miękka
Format: 168x237
Wydawnictwo: Helion
Cena: 77.00zł 57.75zł


Rozwój technik BDD jest odpowiedzią na poważny problem, z którym muszą się zmierzyć zespoły rozwijające oprogramowanie. Tym problemem jest skuteczne komunikowanie i zrozumienie się nawzajem.

Jeśli jesteś kierownikiem projektu, musisz jakoś skłonić programistę do pisania testów, namówić testera do zaakceptowania tych testów i przekonać inwestora, że coś, co nie jest kodem produkcyjnym, może mieć swoją wartość. Okazuje się, że kluczem do sukcesu jest doprowadzenie do sytuacji, w której każdy rozumie, do czego ma służyć aplikacja, jak się ma zachować i jakie są jej kluczowe funkcje. Świetnym narzędziem ułatwiającym taką pracę jest technika BDD - obszerny zbiór najlepszych praktyk i narzędzi wspomagających analizę wymagań i automatyzację testów.

Książka, którą trzymasz w dłoni, stanowi przegląd praktyk BDD na wszystkich poziomach procesu rozwoju oprogramowania. Znajdziesz w niej informacje na temat odkrywania i określania wysokopoziomowych wymagań, implementacji funkcji aplikacji oraz pisania automatycznych testów akceptacyjnych i jednostkowych. Jest ona niezastąpionym przewodnikiem dla analityków biznesowych i deweloperów, testerów, a przede wszystkim liderów i menedżerów projektów.

Dzięki tej książce poznasz:
• teorię i praktykę BDD
• zasady stosowania BDD w pracy zespołowej
• testy akceptacyjne, integracyjne i jednostkowe BDD
• praktyczne przykłady w Javie, .NET, JavaScripcie i innych językach
• sposoby tworzenia raportów i dynamicznej dokumentacji BDD

Już dziś przedstaw swojemu zespołowi rewolucyjne techniki BDD.

John Ferguson Smart — światowej klasy specjalista w dziedzinie BDD, automatycznego testowania i optymalizacji rozwoju oprogramowania w całym cyklu życia, umiejętnie łączący wiedzę programisty i zalety coacha.

Spis treści:

CZĘŚĆ I. PIERWSZE KROKI (23)

Rozdział 1. Budowanie oprogramowania, które sprawia różnicę (25)

  • 1.1. BDD z wysokości 15 kilometrów (27)
  • 1.2. Jakie problemy próbujemy rozwiązywać? (29)
    • 1.2.1. Właściwe budowanie oprogramowania (30)
    • 1.2.2. Budowanie właściwego oprogramowania (32)
    • 1.2.3. Ograniczenia wiedzy - radzenie sobie z informacją niepewną (32)
  • 1.3. Wprowadzenie do programowania sterowanego zachowaniami (34)
    • 1.3.1. BDD pierwotnie zaprojektowano jako ulepszoną wersję TDD (35)
    • 1.3.2. Techniki BDD również sprawdzają się jako narzędzia analizy wymagań (37)
    • 1.3.3. Zasady i praktyki BDD (38)
  • 1.4. Korzyści z BDD (52)
    • 1.4.1. Mniejsze marnotrawstwo (52)
    • 1.4.2. Niższe koszty (52)
    • 1.4.3. Łatwiejsze i bezpieczniejsze zmiany (53)
    • 1.4.4. Szybsze publikacje (53)
  • 1.5. Wady i potencjalne problemy związane ze stosowaniem praktyk BDD (53)
    • 1.5.1. Stosowanie praktyk BDD wymaga dużego zaangażowania i współpracy (53)
    • 1.5.2. Praktyki BDD sprawdzają się najlepiej w kontekście metodologii Agile lub innej metodologii iteracyjnej (53)
    • 1.5.3. Praktyki BDD nie sprawdzają się dobrze w projektach typu silos (54)
    • 1.5.4. Źle napisane testy mogą prowadzić do wyższych kosztów utrzymania (54)
  • 1.6. Podsumowanie (54)

Rozdział 2. BDD z lotu ptaka (57)

  • 2.1. Wprowadzenie w tematykę aplikacji rozkładu jazdy pociągów (58)
  • 2.2. Określenie korzyści ze stosowania proponowanej aplikacji (60)
  • 2.3. Analiza wymagań - odkrywanie i zrozumienie funkcji (60)
    • 2.3.1. Opisywanie funkcji (60)
    • 2.3.2. Podział cech funkcjonalnych na historyjki (62)
    • 2.3.3. Ilustrowanie historyjek przykładami (63)
  • 2.4. Implementacja - budowanie i dostarczanie cech funkcjonalnych (64)
    • 2.4.1. Od przykładów do kryteriów akceptacji (64)
    • 2.4.2. Konfigurowanie narzędzi Maven i Git (65)
    • 2.4.3. Specyfikacje wykonywalne - automatyzacja kryteriów akceptacji (67)
    • 2.4.4. Automatyczne testy - implementacja kryteriów akceptacji (72)
    • 2.4.5. Testy jako dynamiczna dokumentacja (81)
  • 2.5. Utrzymanie (81)
  • 2.6. Podsumowanie (85)

CZĘŚĆ II. CZEGO CHCĘ? DEFINIOWANIE WYMAGAŃ Z WYKORZYSTANIEM BDD (87)

Rozdział 3. Zrozumieć cele biznesowe. Wstrzykiwanie cech funkcjonalnych i związane z tym techniki (89)

  • 3.1. Poznajemy firmę Flying High (91)
  • 3.2. Wstrzykiwanie funkcji (92)
    • 3.2.1. Wyszukiwanie wartości (93)
    • 3.2.2. Wstrzykiwanie cech funkcjonalnych (93)
    • 3.2.3. Wskazanie przykładów (94)
    • 3.2.4. Podsumowanie (94)
  • 3.3. Co chcesz osiągnąć? Zacznij od wizji (96)
    • 3.3.1. Formuła wizji (97)
    • 3.3.2. Korzystanie z szablonów formuły wizji (98)
  • 3.4. W jaki sposób firma skorzysta na projekcie? Identyfikowanie celów biznesowych (99)
    • 3.4.1. Pisanie dobrych celów biznesowych (100)
    • 3.4.2. Pokaż mi pieniądze - cele biznesowe a przychody (101)
    • 3.4.3. Ściąganie ze "stosu dlaczego" - uściślanie celów biznesowych (103)
  • 3.5. Mapowanie wpływu - podejście wizualne (106)
  • 3.6. Kto na tym skorzysta? Identyfikowanie interesariuszy i ich potrzeb (110)
  • 3.7. Co trzeba zbudować? Identyfikowanie zdolności (112)
  • 3.8. Jakie cechy funkcjonalne zapewnią największy wskaźnik ROI? Model dopasowania do celów (114)
    • 3.8.1. Cechy wyróżniające (116)
    • 3.8.2. Cechy równoważne (116)
    • 3.8.3. Cechy partnerskie (117)
    • 3.8.4. Cechy o minimalnym wpływie (117)
  • 3.9. Podsumowanie (117)

Rozdział 4. Definiowanie i ilustrowanie cech funkcjonalnych (119)

  • 4.1. Co to jest cecha funkcjonalna? (120)
    • 4.1.1. Cechy funkcjonalne dostarczają zdolności (122)
    • 4.1.2. Cechy funkcjonalne można podzielić na łatwiejsze do zarządzania fragmenty (126)
    • 4.1.3. Cecha funkcjonalna może być opisana za pomocą jednej lub kilku historyjek użytkowników (128)
    • 4.1.4. Cecha funkcjonalna nie jest historyjką użytkownika (131)
    • 4.1.5. Eposy to naprawdę duże historyjki użytkownika (132)
    • 4.1.6. Nie wszystko pasuje do hierarchii (133)
  • 4.2. Ilustrowanie cech funkcjonalnych przykładami (134)
  • 4.3. Realne opcje - podejmuj zobowiązania dopiero wtedy, kiedy musisz (140)
    • 4.3.1. Opcje mają wartość (141)
    • 4.3.2. Opcje wygasają (143)
    • 4.3.3. Nigdy nie zobowiązuj się zbyt wcześnie, jeśli nie wiesz dlaczego (143)
  • 4.4. Celowe odkrywanie (144)
  • 4.5. Od przykładów do działającego oprogramowania - szerszy obraz (145)
  • 4.6. Podsumowanie (146)

Rozdział 5. Od przykładów do wykonywalnych specyfikacji (149)

  • 5.1. Przekształcanie konkretnych przykładów na wykonywalne scenariusze (151)
  • 5.2. Pisanie wykonywalnych scenariuszy (154)
    • 5.2.1. Plik cech funkcjonalnych zawiera tytuł i opis (154)
    • 5.2.2. Opisywanie scenariuszy (156)
    • 5.2.3. Struktura "Zakładając... Gdy... Wtedy" (157)
    • 5.2.4. Uzupełniające słowa kluczowe (158)
    • 5.2.5. Komentarze (159)
  • 5.3. Wykorzystanie tabel w scenariuszach (160)
    • 5.3.1. Używanie tabel w pojedynczych krokach (160)
    • 5.3.2. Wykorzystanie tabel przykładów (161)
  • 5.4. Scenariusze ekspresywne - wzorce i antywzorce (165)
    • 5.4.1. Pisanie ekspresywnych kroków Zakładając (165)
    • 5.4.2. Pisanie ekspresywnych kroków Gdy (166)
    • 5.4.3. Pisanie ekspresywnych kroków Wtedy (167)
    • 5.4.4. Podawanie tła i kontekstu (168)
    • 5.4.5. Unikanie zależności między scenariuszami (170)
  • 5.5. Organizowanie scenariuszy przy użyciu plików cech funkcjonalnych i tagów (171)
    • 5.5.1. Scenariusze zapisuje się w plikach opisu cech funkcjonalnych (172)
    • 5.5.2. Plik opisu cechy funkcjonalnej może zawierać jeden lub więcej scenariuszy (172)
    • 5.5.3. Organizowanie plików opisu cech funkcjonalnych (173)
    • 5.5.4. Opisywanie scenariuszy za pomocą tagów (174)
  • 5.6. Podsumowanie (176)

Rozdział 6. Automatyzacja scenariuszy (179)

  • 6.1. Wprowadzenie do automatyzowania scenariuszy (182)
    • 6.1.1. Definicje kroków interpretują tekst scenariuszy (182)
    • 6.1.2. Zachowaj prostotę metod definicji kroków (184)
  • 6.2. Implementacja definicji kroków - zasady ogólne (186)
    • 6.2.1. Instalowanie narzędzi BDD (186)
    • 6.2.2. Implementacja definicji kroków (187)
    • 6.2.3. Przekazywanie parametrów do implementacji kroków (187)
    • 6.2.4. Utrzymywanie stanu pomiędzy krokami (188)
    • 6.2.5. Wykorzystywanie danych tabelarycznych z definicji kroków (190)
    • 6.2.6. Implementacja scenariuszy bazujących na przykładach (191)
    • 6.2.7. Wyniki scenariusza (192)
  • 6.3. Bardziej efektywna implementacja BDD z wykorzystaniem narzędzia Thucydides (193)
  • 6.4. Automatyzowanie scenariuszy w Javie z wykorzystaniem JBehave (194)
    • 6.4.1. Instalowanie i konfigurowanie narzędzia JBehave (194)
    • 6.4.2. Definicje kroków JBehave (195)
    • 6.4.3. Współdzielenie danych pomiędzy krokami (197)
    • 6.4.4. Przekazywanie tabel do kroków (198)
    • 6.4.5. Definicje kroków dla tabel przykładów (199)
    • 6.4.6. Warianty wzorców (200)
    • 6.4.7. Niepowodzenia i błędy w wynikach scenariuszy (200)
  • 6.5. Automatyzowanie scenariuszy w Javie przy użyciu narzędzia Cucumber-JVM (202)
    • 6.5.1. Konfiguracja i struktura projektu Cucumber-JVM (202)
    • 6.5.2. Definicje kroków Cucumber-JVM (203)
    • 6.5.3. Warianty wzorców (204)
    • 6.5.4. Przekazywanie tabel do definicji kroków (205)
    • 6.5.5. Definicje kroków dla tabel przykładów (206)
    • 6.5.6. Współdzielenie danych pomiędzy krokami (206)
    • 6.5.7. Kroki oczekujące i wyniki kroków (207)
  • 6.6. Automatyzowanie scenariuszy w Pythonie z wykorzystaniem Behave (207)
    • 6.6.1. Instalacja systemu Behave (208)
    • 6.6.2. Struktura projektu Behave (208)
    • 6.6.3. Definicje kroków Behave (209)
    • 6.6.4. Łączenie kroków (209)
    • 6.6.5. Definicje kroków z wykorzystaniem osadzonych tabel (210)
    • 6.6.6. Definicje kroków dla tabel przykładów (210)
    • 6.6.7. Uruchamianie scenariuszy w Behave (210)
  • 6.7. Automatyzowanie scenariuszy w .NET z wykorzystaniem SpecFlow (211)
    • 6.7.1. Konfigurowanie SpecFlow (211)
    • 6.7.2. Dodawanie plików opisu cech funkcjonalnych (211)
    • 6.7.3. Uruchamianie scenariuszy (213)
    • 6.7.4. Definicje kroków w SpecFlow (213)
    • 6.7.5. Współdzielenie danych pomiędzy krokami (214)
    • 6.7.6. Definicje kroków z wykorzystaniem tabel przykładów (215)
  • 6.8. Automatyzowanie scenariuszy w JavaScript z wykorzystaniem systemu Cucumber-JS (216)
    • 6.8.1. Konfigurowanie systemu Cucumber-JS (216)
    • 6.8.2. Pisanie plików opisu funkcji w Cucumber-JS (217)
    • 6.8.3. Implementowanie kroków (218)
    • 6.8.4. Uruchamianie scenariuszy (219)
  • 6.9. Podsumowanie (220)

CZĘŚĆ III. JAK TO ZBUDOWAĆ? KODOWANIE ZGODNE Z BDD (219)

Rozdział 7. Od wykonywalnych specyfikacji do solidnych automatycznych testów akceptacyjnych (223)

  • 7.1. Pisanie niezawodnych testów akceptacji (225)
  • 7.2. Automatyzowanie procesu konfiguracji testu (228)
    • 7.2.1. Inicjowanie bazy danych przed każdym testem (228)
    • 7.2.2. Inicjowanie bazy danych na początku zestawu testów (229)
    • 7.2.3. Korzystanie z haków inicjalizacji (229)
    • 7.2.4. Konfigurowanie danych specyficznych dla scenariusza (233)
    • 7.2.5. Użycie person i znanych encji (235)
  • 7.3. Oddzielenie warstwy "co" od warstwy "jak" (237)
    • 7.3.1. Warstwa reguł biznesowych opisuje oczekiwane rezultaty (238)
    • 7.3.2. Warstwa przepływu pracy opisuje działania użytkownika (239)
    • 7.3.3. Warstwa techniczna realizuje interakcje z systemem (241)
    • 7.3.4. Ile warstw? (242)
  • 7.4. Podsumowanie (243)

Rozdział 8. Automatyzacja kryteriów akceptacji dla warstwy interfejsu użytkownika (245)

  • 8.1. Kiedy i jak należy testować interfejs użytkownika? (247)
    • 8.1.1. Zagrożenie zbyt wieloma testami webowymi (247)
    • 8.1.2. Testy webowe z przeglądarkami w trybie headless (248)
    • 8.1.3. Ile testów webowych naprawdę potrzebujemy? (250)
  • 8.2. Automatyzowanie webowych kryteriów akceptacji z wykorzystaniem programu Selenium WebDriver (251)
    • 8.2.1. Pierwsze kroki z WebDriver w Javie (252)
    • 8.2.2. Identyfikacja elementów strony WWW (255)
    • 8.2.3. Interakcje z elementami stron WWW (263)
    • 8.2.4. Praca ze stronami asynchronicznymi i testowanie aplikacji AJAX (265)
    • 8.2.5. Pisanie aplikacji webowych "przyjaznych dla testów" (267)
  • 8.3. Korzystanie z obiektów stron w celu poprawy czytelności testów (267)
    • 8.3.1. Wprowadzenie do wzorca Obiekty stron (268)
    • 8.3.2. Pisanie dobrze zaprojektowanych obiektów stron (273)
    • 8.3.3. Korzystanie z bibliotek rozszerzających bibliotekę WebDriver (279)
  • 8.4. Podsumowanie (281)

Rozdział 9. Automatyzacja kryteriów akceptacji dla wymagań niekorzystających z UI (283)

  • 9.1. Równowaga pomiędzy testami akceptacyjnymi z wykorzystaniem UI i bez UI (285)
  • 9.2. Kiedy używać testów akceptacji bez pośrednictwa UI (286)
  • 9.3. Typy automatycznych testów akceptacji niekorzystających z UI (290)
    • 9.3.1. Testowanie z wykorzystaniem warstwy kontrolera (291)
    • 9.3.2. Bezpośrednie testowanie logiki biznesowej (295)
    • 9.3.3. Testowanie warstwy usług (299)
  • 9.4. Definiowanie i testowanie wymagań niefunkcjonalnych (304)
  • 9.5. Odkrywanie projektu (306)
  • 9.6. Podsumowanie (308)

Rozdział 10. BDD a testy jednostkowe (309)

  • 10.1. BDD, TDD a testy jednostkowe (310)
    • 10.1.1. BDD dotyczy pisania specyfikacji, a nie testów, na wszystkich poziomach (312)
    • 10.1.2. BDD bazuje na ugruntowanych praktykach TDD (313)
    • 10.1.3. Narzędzia BDD do testów jednostkowych (313)
  • 10.2. Od kryteriów akceptacji do zaimplementowanych cech funkcjonalnych (313)
    • 10.2.1. BDD sprzyja stosowaniu podejścia "z zewnątrz do wewnątrz" (314)
    • 10.2.2. Zaczynamy od wysokopoziomowego kryterium akceptacji (316)
    • 10.2.3. Automatyzacja scenariuszy kryteriów akceptacji (317)
    • 10.2.4. Implementacja definicji kroków (317)
    • 10.2.5. Zrozumienie modelu domeny (318)
    • 10.2.6. Pisanie kodu, który chcielibyśmy mieć (319)
    • 10.2.7. Wykorzystanie kodu definicji kroku do wyspecyfikowania i zaimplementowania kodu aplikacji (319)
    • 10.2.8. W jaki sposób stosowanie praktyk BDD pomogło? (324)
  • 10.3. Analiza niskopoziomowych wymagań, odkrywanie projektu i implementacja bardziej złożonych funkcjonalności (325)
    • 10.3.1. Wykorzystanie kodu definicji kroku do analizy niskopoziomowego projektu (326)
    • 10.3.2. Praca z tabelami przykładów (328)
    • 10.3.3. Odkrywanie nowych klas i usług w miarę implementowania kodu produkcyjnego (330)
    • 10.3.4. Natychmiastowa implementacja prostych klas lub metod (331)
    • 10.3.5. Wykorzystanie minimalnej implementacji (331)
    • 10.3.6. Wykorzystanie namiastek i makiet w celu odroczenia implementacji bardziej złożonego kodu (332)
    • 10.3.7. Rozwijanie niskopoziomowych specyfikacji technicznych (333)
  • 10.4. Narzędzia, dzięki którym testy jednostkowe BDD stają się łatwiejsze (336)
    • 10.4.1. Stosowanie praktyk BDD z tradycyjnymi narzędziami testów jednostkowych (336)
    • 10.4.2. Pisanie specyfikacji, a nie testów - rodzina RSpec (339)
    • 10.4.3. Pisanie bardziej ekspresywnych specyfikacji z wykorzystaniem narzędzi Spock albo Spec2 (343)
  • 10.5. Używanie wykonywalnych specyfikacji jako dynamicznej dokumentacji (345)
    • 10.5.1. Używanie płynnego kodowania w celu poprawy czytelności (346)
    • 10.5.2. Płynne asercje w języku JavaScript (347)
    • 10.5.3. Płynne asercje w językach statycznych (347)
  • 10.6. Podsumowanie (349)

CZĘŚĆ IV. ZAAWANSOWANE ASPEKTY BDD (349)

Rozdział 11. Dynamiczna dokumentacja - raportowanie a zarządzanie projektem (353)

  • 11.1. Dynamiczna dokumentacja - widok wysokopoziomowy (354)
  • 11.2. Czy osiągnęliśmy cel? Raporty dotyczące gotowości i pokrycia cech funkcjonalnych (356)
    • 11.2.1. Gotowość cech funkcjonalnych - jakie cechy są gotowe do dostarczenia (356)
    • 11.2.2. Pokrycie cechy funkcjonalnej - jakie wymagania zostały spełnione (357)
  • 11.3. Integracja z cyfrowym rejestrem projektu (360)
  • 11.4. Organizowanie dynamicznej dokumentacji (362)
    • 11.4.1. Organizowanie dynamicznej dokumentacji według wysokopoziomowych wymagań (363)
    • 11.4.2. Organizowanie dynamicznej dokumentacji z wykorzystaniem tagów (364)
    • 11.4.3. Dynamiczna dokumentacja do tworzenia raportów na temat publikacji oprogramowania (364)
  • 11.5. Dostarczanie dokumentacji w luźniejszej formie (366)
  • 11.6. Techniczna dynamiczna dokumentacja (368)
    • 11.6.1. Testy jednostkowe jako dynamiczna dokumentacja (369)
    • 11.6.2. Dynamiczna dokumentacja dla starszych aplikacji (371)
  • 11.7. Podsumowanie (372)

Rozdział 12. BDD w procesie budowania (373)

  • 12.1. Wykonywalne specyfikacje powinny być częścią automatycznego procesu budowy (374)
    • 12.1.1. Każda specyfikacja powinna być samowystarczalna (375)
    • 12.1.2. Wykonywalne specyfikacje powinny być przechowywane w systemie kontroli wersji (376)
    • 12.1.3. Powinna istnieć możliwość uruchomienia wykonywalnych specyfikacji z wiersza polecenia (377)
  • 12.2. Ciągła integracja przyspiesza cykl sprzężenia zwrotnego (378)
  • 12.3. Ciągłe dostawy - każda kompilacja jest potencjalną wersją do opublikowania (380)
  • 12.4. Strategia ciągłej integracji w celu wdrażania dynamicznej dokumentacji (383)
    • 12.4.1. Publikowanie dynamicznej dokumentacji na serwerze kompilacji (384)
    • 12.4.2. Publikowanie dynamicznej dokumentacji na dedykowanym serwerze WWW (385)
  • 12.5. Szybsze zautomatyzowane kryteria akceptacji (385)
    • 12.5.1. Uruchamianie równoległych testów akceptacyjnych w obrębie zautomatyzowanego procesu budowy (386)
    • 12.5.2. Uruchamianie równoległych testów na wielu maszynach (388)
    • 12.5.3. Uruchamianie równoległych testów webowych z wykorzystaniem Selenium Grid (391)
  • 12.6. Podsumowanie (395)
  • 12.7. Ostatnie słowa (396)

Najniższa cena z 30 dni przed obniżką 57,75zł

BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji
Tytuł książki: "BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji"
Autor: John Ferguson Smart
Wydawnictwo: Helion
Cena: 77.00zł 57.75zł
Klienci, którzy kupili „BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji”, kupili także:

Samba 4 Przewodnik administratora, Marcelo Leal, Wydawnictwo Helion

Sass. Nowoczesne arkusze stylów, Bartosz Chucherko, Wydawnictwo Helion

Ansible w praktyce. Automatyzacja konfiguracji i proste instalowanie systemów. Wydanie II, Lorin Hochstein, Rene Moser, Wydawnictwo Helion

Docker. Projektowanie i wdrażanie aplikacji, Jaroslaw Krochmalski, Wydawnictwo Helion

Adaptywny kod. Zwinne programowanie, wzorce projektowe i SOLID-ne zasady. Wydanie II, Gary McLean Hall, Wydawnictwo Helion

C++17 STL Receptury, Jacek Galowicz, Wydawnictwo Helion

czwartek, 28 marca 2024   Mapa strony |  Nowości |  Dzisiejsze promocje |  Koszty wysyłki |  Kontakt z nami