Automatiseret Test & Continuous Integration Rikke Simonsen & Mads Danquah
Hvem er vi?
Danmarks førende tekniske eksperter!i Drupal CMS rådgivning og udvikling
! Mads Danquah, Udvikler Implementerer funktionalitet i samarbejde med kunde, projektleder og tester. Bidrager med ekspertviden om, hvad man kan - så fokus kan blive på, hvor man vil hen.! Rikke Simonsen, Tester! Planlægger og udfører tests af funktionalitet. Skriver specifikationer sammen med kunden og implementer dem som automatiserede tests.
Hvad vil vi fortælle om?
Om hvordan du i agil softwareudvikling sikrer høj udviklingshastighed og høj kodekvalitet når udviklingscyklusen er kort og nye features releases ofte
1. Agil softwareudvikling 2. Behavior Driven Development 3. Automatiseret test 4. Kort pause (10 min) 5. Vores udviklingsproces 6. Continuous Integration
Agil softwareudvikling
Det agile manifest Individer og interaktioner over processer og værktøjer Fungerende software over omfattende dokumentation Samarbejde med kunden over kontraktforhandlinger Reagere på ændringer over at følge en plan
Behavior Driven Development
TDD
http://dannorth.net/introducing-bdd/ I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails. Dan North, 2006
Eksempel 1 Egenskab: Fritekstsøgning på arrangement For at kunne finde arrangementer der kunne interessere mig Som medlem af IDA Vil jeg gerne kunne foretage en fritekstsøgning på titel! Baggrund: Givet arrangementet Gå-hjem-møde: Automatiseret Test & Continuous Integration eksisterer! Scenarie: Søgning på del af titel Givet jeg er på siden Arrangementer Når jeg udfører en fritekstsøgning på teksten Continuous Integration Så skal søgeresultatet indeholde arrangementet Gå-hjemmøde: Automatiseret Test & Continuous Integration
Skriv din test i Gherkin (på dansk) Egenskab: [Titel på feature] For at [opnå et givent mål] Som [bruger/rolle] Vil jeg have [feature]! Baggrund: [Valgfri beskrivelse] Givet [Forudsætning]! Scenarie: [Valgfri beskrivelse] Givet [Forudsætning] Når [Erklæring] Og [en anden erklæring] Så [Postcondition] Men [en anden postcondition]! [Flere scenarier]
Eller på engelsk Feature: [Title of the feature] In order to [achieve some goal] As a [user/role] I want to [do action]! Background: [Optional description] Given [Precondition]! Scenario: [Optional description] Given [Precondition] When [Statement] And [another statement] Then [Postcondition] But [another postcondition]! [more scenarios]
Eksempel 2 Feature: One or more images available on ads when First Class Member In order to differentiate the memberships As a site owner The First Class Members can upload multiple images per ad! Scenario Outline: Create an ad with images Given I am on homepage And I log in as the user "First Class Seller" When I create the ad "Cocktail Dress" with <Number of images> Then I should see <Message>! Examples: Number of images Message 0 "Billede af annoncen skal udfyldes" 1 "Product Cocktail Dress er blevet oprettet" 3 "Product Cocktail Dress er blevet oprettet"
Automatiseret test
DEMO
Cucumber for Ruby JBehave for Java NBehave and SpecFlow for C# Freshen for Python Behat for PHP
DEMO
DEMO
10 minutters pause
Continuous Integration og hvordan vi gør det
Præmissen for at vi kan gøre hvad vi gør i Reload Vi har rigtig dygtige folk der kan alt Vores folk må alt (f.eks. release til produktion) Vi gifter os ikke med værktøjer eller processer og tager dem regelmæssigt op til revurdering - findes der et bedre værktøj til opgaven bruger vi det hellere end at hænge i fortiden.
Omstændigheder og råstoffet Vi er i et felt der traditionelt er lidt rodet, præget af travlhed og manglende best practices En dygtig webudvikler er ikke nødvendigvis højtuddannet Vi går derfor efter dygtige (uagtet baggrund), og sikre kvaliteten vha. væktøjer, process og kultur.
Et kik i værktøjskassen! (pr. september 2014) SCM: Git (hosted hos Github) Issuetracker: JIRA Build: Jenkins, CircleCI, Grunt, Drake (hjemmebrygget) Codestyle og lignende: Scrutinizer, phploc, phpcs, pmd Udviklingsværktøj: PhpStorm, Sublime, emacs, vim Vi kan godt lide cloudløsninger!
Tech Vi arbejder efter Continuous Integration - dvs få branches der lever i kort tid (timer til få dage)! Branch + merge pr. issue
Et par vigtige detaljer Ideelt har vi den fulde kode-base samlet i ét repository. Der er ikke noget i vores sites der skal compiles. Vi kan release direkte fra Git. Dvs, det der ligger i produktion er det samme bit for bit som det der ligger i vores repository
Udviklingsprocess Implementering af et issue Review Test (gentag til sprintet er slut) Release
Implementering Gennemlæse issue Branche af fra develop Implementere rettelsen lokalt Test lokalt DEMO
Review Målet med et review er at få en andens øjne på koden. Vi har ikke nogen formelle regler for et review. Vi bruger vi Githubs udemærkede pull-requests DEMO
Test Deployment til et test-miljø Verifikation af tester / forretningen Branche af fra develop Implementere rettelsen lokalt Test lokalt DEMO
Release Udviklingsbranchen merges i release Evt sidste automatiske tests Der deployes - evt bare med et git checkout
Fremtiden - ting på vores ønskeliste Blive bedre til unittests - Drupal (og en del andre CMS-systemer) har syltet tingene sammen Blive bedre til at styre konfiguration vs kode Begynde at teste imod kendte konfigurations og indholds baselines Automatiske deployments i forbindelse med merge Optimere endnu mere på processen :)
Spørgsmål
Kontakt os: rikke@reload.dk mads@reload.dk!!