-
Notifications
You must be signed in to change notification settings - Fork 1
/
index.html
474 lines (391 loc) · 14 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<title>Testing with behat, and why it matters</title>
<meta name="author" content="Valery 'valthebald' Lourie"/>
<meta name="apple-mobile-web-app-capable" content="yes"/>
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent"/>
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"/>
<link rel="stylesheet" href="css/reveal.min.css">
<link rel="stylesheet" href="css/mentoring/source/mentoring.css" id="theme">
<!-- For syntax highlighting -->
<link rel="stylesheet" href="lib/css/zenburn.css">
<!-- If the query includes 'print-pdf', use the PDF print sheet -->
<script>
document.write('<link rel="stylesheet" href="css/print/' + ( window.location.search.match(/print-pdf/gi) ? 'pdf' : 'paper' ) + '.css" type="text/css" media="print">');
</script>
<!--[if lt IE 9]>
<script src="lib/js/html5shiv.js"></script>
<![endif]-->
</head>
<body>
<div class="reveal">
<!-- Any section element inside of this container is displayed as a slide -->
<section class="slides">
<section>
<h3><a href="http://tinyurl.com/behathow">tinyurl.com/behathow</a></h3>
<br/>
<h3>Let's talk testing:</h3>
<aside class="notes">
<p>
Slides are hosted on github, press 's' if you want to read speaker notes too.
</p>
</aside>
</section>
<section>
<h3>Testing classification</h3>
<h4>When is it performed</h4>
<ul>
<li>Static</li>
<li>Dynamic</li>
</ul>
<aside class="notes">
<p>
Static tests analyze software source code, even before it runs
Dynamic tests run when the software under test runs
</p>
</aside>
</section>
<section>
<h3>Testing classification (2)</h3>
<h4>What we know</h4>
<ul>
<li>White box</li>
<li>Black box</li>
<li>Grey box</li>
</ul>
<aside class="notes">
<p>
White box - we know internal design of the system under test
Box - we don't know internal design
Grey box is when we know (at least partially) software design,
but run tests as af it's a black box
</p>
</aside>
</section>
<section>
<h3>Testing classification (3)</h3>
<h4>When we test</h4>
<ul>
<li>Install</li>
<li>Update</li>
<li>Adding / removing / updating a component</li>
<li>Regular basis</li>
</ul>
<aside class="notes">
<p>
There are tests that should run when system changes, or on a regular basis.
Regular checks help to reveal problems that occur under certain circumstances.
</p>
</aside>
</section>
<section>
<h3>Testing classification (4)</h3>
<h4>What we test</h4>
<ul>
<li>Unit / Component</li>
<li>Integration</li>
<li>System / Functional</li>
<li>Operational Acceptance</li>
</ul>
<aside class="notes">
<p>
Are we testing single component? then it's unit.
Are we testing interaction of several components? It's integration
Is it certain user stories, end to end testing of the product as a whole?
We also have operational acceptance tests, i.e. sanity checks before going live
</p>
</aside>
</section>
<section>
<h3>It's Agile, baby</h3>
<img class="fragment" src="images/truth-consequences.jpg" alt="Truth or consequences" />
<h4>OMG panic</h4>
<ul>
<li class="fragment">Static tests - git hooks</li>
<li class="fragment">Dynamic - CI</li>
</ul>
<aside class="notes">
Did I say live?
Going live! Time have changed, so we go live every day (sometimes multiple times)
Agile process means we're always live
We have to know the truth about the code (or have consequences)
Out product must be stable, stable means quality. Quality assurance becomes central!
We never can be 100% sure, but having good test coverage is crucial.
You add a new feature, you need to be sure it doesn't break existing ones. Best case if we can use
all types of testing.
We perform static testing in git hooks - syntax errors, code style etc, commit messages etc.
For dynamic testing, we use CI tools - Jenkins, Codeship, Travis etc.
</aside>
</section>
<section>
<h3>Unit testing with Drupal sites</h3>
<h4>Units have to be isolated, and testable</h4>
<div><img src="images/meme-testable.jpg" class="fragment " alt=""/></div>
<ul>
<li class="fragment">D6 - impossible</li>
<li class="fragment">D7 - impractical</li>
<li class="fragment">D8 - irrelevant?</li>
</ul>
<aside class="notes">
Let's focus on dynamic testing, and start with components testing.
Isolated unit - means that it's output doesn't depend on anything except its own state.
Testable unit - you can clearly define expected output, if you know input.
You cannot simply make a unit testable, you have to design the whole project to do it
(and it's not always possible - i.e. you got a ready codebase from someone else)
Let's be more specific, and talk about testing of Drupal-based systems. We have the core,
the contrib, and then our custom functionality, in custom modules and themes.
There was no standard way to unit test Drupal 6
Drupal 7 has simpletest in contrib, which works, but has its issues.
Drupal 8 has more testable structure.
In case of any Drupal core version, we can assume that it "just works". And if it's not, there are
enough eyes to see the problem.
</aside>
</section>
<section>
<h3>Typical issue flow</h3>
<ul>
<li>User story</li>
<li>Acceptance criteria</li>
<li>Technical description</li>
<li>Implementation</li>
<li>Design</li>
<li>QA</li>
</ul>
<aside class="notes">
I do know deny unit tests, but system tests are way more important for end client projects.
Here's the typical issue flow.
We have agreed that quality is crucial for agile projects, why we start thinking about it in the end?
</aside>
</section>
<section>
<h3>Example</h3>
<img src="images/jira-issue.png" alt="JIRA" />
<aside class="notes">
In most practical situations, we don't need or cannot write unit tests
</aside>
</section>
<section>
<h3>What if it looked different?</h3>
<div class="fragment grow"><pre class="fragment shrink" style="border: black 1px solid">
Feature: Core - Login & Logout
As an anonymous user
I can find a box/link for login on any page
I'll remain on the same page except from HP
</pre>
</div>
<pre style="border: black 1px solid">
Background:
Given I am an anonymous user
Scenario: Login from the homepage
When I go to the homepage
Then I need to see a link to login
When I press the login link
And I login as myusername
Then the current page is dashboard
</pre>
<div class="fragment grow">
<pre class="fragment shrink">
Scenario: Login from random page
When I go to random page
Then I need to see a link to login
When I press the login link
And I login as myusername
Then the current page is random page
</pre>
</div>
<aside class="notes">
Sounds familiar to some of you at this point? Welcome to behat!
We achieve 2 fundamental goals:
Active criteria that is formal (we like formalized things)
Know how to test even before functionality is implemented
</aside>
</section>
<section>
<h3>How it works</h3>
<ul>
<li>Scenarios (*.feature)</li>
<li>Feature contexts</li>
<li>Project settings (behat.yml)</li>
</ul>
<aside class="notes">
This is Benat - behavior driven framework for PHP
What we saw on the previous slide is behat feature.
Behat feature consists of steps. Every step is a PHP method of feature context
Feature context is a php class, usually named FeatureContext. There can be more than one
</aside>
</section>
<section>
<h3>Evaluate a test</h3>
<div class="fragment">
When I go to the homepage
</div>
<pre class="fragment"><code>
# features/bootstrap/FeatureContext.php
<?php
use Behat\Behat\Context\BehatContext,
Behat\Behat\Exception\PendingException;
use Behat\Gherkin\Node\PyStringNode,
Behat\Gherkin\Node\TableNode;
class FeatureContext extends BehatContext
{
/**
* @When /^I go to the homepage$/
*/
public function iGoToTheHomePage()
{
// ...your code here
}
/**
* @When /^I login as "([^"]+)"$/
*/
public function iLoginAs($username)
{
// ...your code here
}
}
?>
</code>
</pre>
<aside class="notes">
For every sentence in scenario, we need to know how to evaluate it.
All steps definitions have to be defined in feature context class
Step definition can have parameters, taken as regular expressions from function docblock
If something goes wrong, we throw an exception. That's it
Every step has 3 possible results:
- step definition is not found
- step definition function executes and throws an exception
- step definition function executes with no exception (success)
</aside>
</section>
<section>
<h3>This sounds like enormous amount of work!</h3>
<ul>
<li>Mink</li>
<li>Drupal</li>
<li>REST API</li>
</ul>
<aside class="notes">
PHP inheritance to the resque! You can reuse step definitions defined by base feature context classes.
Mink - browser emulator, can work with real browser or headless browser like phantom
Drupal - drupal step definitions (create node/term/user, login, logout etc.)
You may still need your own step functions - extend FeatureContext class
</aside>
</section>
<section>
<h3>What if I need to test Drupal REST API?</h3>
<ul>
<li>Subcontexts</li>
<li>Multiple contexts</li>
<li>Multiple test suites</li>
</ul>
</section>
<section>
<h3>behat.yml</h3>
<pre>
default:
extensions:
Behat\MinkExtension:
base_url: http://username:[email protected]/
Drupal\DrupalExtension:
blackbox: ~
api_driver: 'drush'
drush:
alias: 'local.default'
suites:
default:
filters:
tags: ~@mobile_api
contexts:
- Drupal\DrupalExtension\Context\MinkContext:
- Drupal\DrupalExtension\Context\MessageContext:
- Drupal\DrupalExtension\Context\DrushContext:
- FeatureContext:
- ['admin','passwordofadmin', '/user/login/']
mobileapi:
filters:
tags: @mobile_api
contexts:
- MobileApiContext:
- {'base_uri': 'http://username:password/', 'api-key': 'apikeytotestlocally'}
</pre>
</section>
<section>
<h3>Better issue flow</h3>
<ul>
<li>User story</li>
<li>Acceptance criteria</li>
<li class="fragment" data-fragment-index="2"><span style="color:green">Write the feature</span> </li>
<li>Technical description</li>
<li>Implementation</li>
<li>Design</li>
<li class="fragment fade-out" data-fragment-index="1"><span style="color:red">QA</span></li>
<li class="fragment" data-fragment-index="3"><span style="color:green">QA</span></li>
</ul>
<aside class="notes">
Before implementing the story, developer should understand what will be tested.
Do we have all step definitions to test?
If not, then developer should review with QA and decide what to do.
Make a new context class? Extend existing class? Use 3d party base class?
This is a change in developer's mindset.
</aside>
</section>
<section>
<h3>References</h3>
<ul>
<li>http://behat.org</li>
<li>http://mink.behat.org - Mink Extension</li>
<li>http://phantomjs.org/</li>
<li>https://www.drupal.org/project/drupalextension - Drupal extension</li>
<li>https://github.com/Behat/WebApiExtension - Web Api extension</li>
</ul>
</section>
<section>
<h3>Give feedback please</h3>
<h3>Questions?</h3>
<br/>
<h4>@valthebald</h4>
</section>
</div>
</div>
<script src="lib/js/head.min.js"></script>
<script src="js/reveal.min.js"></script>
<script>
// Full list of configuration options available here:
// https://github.com/hakimel/reveal.js#configuration
Reveal.initialize({
controls: true,
progress: true,
history: true,
center: true,
theme: Reveal.getQueryHash().theme, // available themes are in /css/theme
transition: Reveal.getQueryHash().transition || 'default', // default/cube/page/concave/zoom/linear/fade/none
// Optional libraries used to extend on reveal.js
dependencies: [
{ src: 'lib/js/classList.js', condition: function () {
return !document.body.classList;
} },
{ src: 'plugin/markdown/marked.js', condition: function () {
return !!document.querySelector('[data-markdown]');
} },
{ src: 'plugin/markdown/markdown.js', condition: function () {
return !!document.querySelector('[data-markdown]');
} },
{ src: 'plugin/highlight/highlight.js', async: true, callback: function () {
hljs.initHighlightingOnLoad();
} },
{ src: 'plugin/zoom-js/zoom.js', async: true, condition: function () {
return !!document.body.classList;
} },
{ src: 'plugin/notes/notes.js', async: true, condition: function () {
return !!document.body.classList;
} }
// { src: 'plugin/search/search.js', async: true, condition: function() { return !!document.body.classList; } }
// { src: 'plugin/remotes/remotes.js', async: true, condition: function() { return !!document.body.classList; } }
]
});
Reveal.addEventListener('fragmentshown')
</script>
</body>
</html>