Application Quality

Joint presentation of Marijus Kilmanas and me on application quality with Behat and Phpspec.

Demo code: https://github.com/asarturas/bdd-demo-petition-website
Demo video (without commentaries): https://www.dropbox.com/sh/bmru6po6khybv0p/QaLfyLL8-h?lst

Transcript

1. Application Quality What is it? How to create it? How to maintain it? Why should I care? @ KaunasPHP v.7
2. Who are we? Artūras Šmorgun http://asm.lt @asarturas Marijus Kilmanas http://about.me/mkilmanas @mkilmanas
3. Why are we here? • Because quality matters; • Because we care about the reputation of our craft and the craftsmen; • Because there is a way to sleep calm at night.
4. Software Quality? What is quality?
15. What if we ignore quality? External Quality
16. What if we ignore quality? Internal Quality
17. “But it slows us down”
18. “But it slows us down”
19. Are we responsible? • We are professionals • quality is expected • We are craftsmen • we should do our job to the best • Quality = recommendation • trust of customers
20. Maintaining quality • Continuos integration • Continuos refactoring
21. Why we need tests? • Refactoring without tests is... • Pain • Insane • Suicide • Refucktoring ...
22. External Quality
23. Cycles of life External Internal
24. Let’s speak Gherkin!
25. Let’s speak Gherkin! In order to cooperate As developers / agency We need to have a common language • States the business value; • Defines the beneficiary; • Gives an idea of what is needed to achieve value.
26. Scenario: Customer understands Gherkin Given I produce feature specification When customer reads them Then they should understand what we agree upon • Lists assumptions and preconditions; • Defines what action triggers the behavior; • Tells how to verify if behavior was correct; Let’s speak Gherkin!
27. Scenario: Gherkin can be tested Given customer confirmed the feature When when we implement them Then we should be able to verify they conform to the agreed requirements • Defines exactly how much functionality is needed; • Automates acceptance criteria; • Guides development process; Let’s speak Gherkin!
29. Example feature file
30. Step code: Given
31. Step code: When
32. Step code: When
33. Step code: Then
35. Mink Webdrivers • Goutte (headless) • Selenium (full browser) • Selenium2 (modern selenium) • Sahi (selenium on JS) • Zombie.js (headless JS browser) • Phantom.js (headless JS browser)
36. Sessions • Used within a single scenario; • Represents state of the browser; • Page object is a sub-property; • Allows different browser for separate scenarios.
37. Common pitfalls • Too technical; • Too enterprise’y; • Coupled with dataset / environment.
38. Internal Quality
39. Cycles of life External Internal
40. Motivation • Wo do make mistakes; • Integration testing is expensive; • Testing afterwards is boring; • “Test last” encourages to skip it; • We want to code, not to debug.
41. TDD Telecommunication Device for the Deaf Test Driven Development
42. What TDD is not: • It’s not about verifying; • It’s not about “waterfall”; • It’s not for fast hacks.
43. What TDD is: • It’s about communication; • It’s about being agile; • It’s for long term relationships.
44. 3 rules of TDD: • Do not write production code unless there is failing test; • Do not write more test than it is sufficient to fail; • Do not write more production code than it is sufficient to pass failing test.
45. TDD cycle
47. Problems? • A lot of scaffolding have to be done in order to write test; • Mocking is expensive (time = money); • Misleading terminology.
48. TDD v2.0 TDD Done Right
49. Spec BDD It’s not about verification, it’s about emerging design.
50. TDD ⇾ BDD • Test Case ⇾ Specification • Test ⇾ Example • Assertion ⇾ Expectation
52. PhpSpec • Easy to use: • does boring stuff for you; • mocking & stubbing is very easy; • TDD cycle oriented; • Behavior oriented: • encourages specification by example.
53. Installation
54. composer.json { ”require-dev”: { ”phpspec/phpspec”: ”2.0.*@dev” }, ”config”: { ”bin-dir”: ”bin” }, ”autoload”: { ”psr-0”: {””: “src”}} }
55. Run! $ curl http://getcomposer.org/installer | php $ php composer.phar install --dev
56. Usage
57. Generate Spec RED
58. Edit spec RED
59. Run specs RED
60. Run specs RED
61. Run specs RED
62. Edit code GREEN
63. Edit code GREEN
64. Run specs REFACTOR
65. Matchers
66. Identity (===) shouldBe() shouldReturn() shouldBeEqualTo() shouldEqual()
67. Identity (===) Expectation: Will match:
68. Comparison (==) shouldBeLike()
69. Comparison (==) Expectation: Will match:
70. Throw shouldThrow()->during()
71. Throw Expectation: Will match:
72. Type beAnInstanceOf() returnAnInstanceOf() haveType()
73. Type Expectation: Will match:
74. Object State has -> have is -> be
75. has -> have Expectation: Will match:
76. is -> be Expectation: Will match:
77. Inline Matchers you can also define your own matchers
78. Let & Let go
79. ->beConstructedWith() Spec: Code:
80. Doubles
81. Doubles • Dummy • Fake • Mock • Stub • Spy ←Control indirect output ←Messaging ←No behavior
82. No behavior
83. Messaging
84. Indirect output
85. Questions?
86. “Live” Demo
87. “Live” Demo • Code: • https://github.com/asarturas/bdd- demo-petition-website • Video (without commentaries, sorry): • https://www.dropbox.com/sh/ bmru6po6khybv0p/QaLfyLL8-h#/
88. Recap
89. We are professionals! Quality is expected
90. Quality Internal & External
91. Create and maintain External Internal
92. Inviqa provides training • on Professional PHP and OOD • on Agile development • on collaborative BDD approach • on full stack BDD in use • on git & git flow • and many more
93. We are looking for team mates! Senior Software Engineers, passionate about their job. (but we mean it!) Kaunas, London, Liverpool, Sheffield, Manchester, Edinburgh, Leeds.
94. Thank you!