-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathindex.html
502 lines (403 loc) · 17.8 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
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Specification by Example | Concordion</title>
<meta name="keywords" content="Specification by Example" />
<meta name="description" content="An open source tool for automating Specification by Example." />
<link media="all" rel="stylesheet" type="text/css" href="css/default.css"/>
<link media="print" rel="stylesheet" type="text/css" href="css/print.css"/>
<link rel="icon" type="image/vnd.microsoft.icon" href="favicon.ico" />
<style>
.subtext {
font-size: 13pt;
}
.keyBenefits p {
font-size: 11pt;
width: 480px;
}
h2 {
font-size: 18pt;
}
.content {
xbackground: url("image/girl-quote.png") no-repeat;
xbackground-position: 410px 50px;
background-color: #fcfcfa !important;
}
.crashCourse {
background-color: #f9f9f7;
border: 1px solid #eee;
padding: 16px;
width: 600px;
margin-left: 40px
}
.crashCourse table {
border-collapse: collapse;
border: 1px solid black;
}
.crashCourse td, .crashCourse th {
border: 1px solid black;
padding: 4px 8px 4px 8px;
background-color: #fff;
}
.crashCourse th {
background-color: #eee;
}
.miniQuote {
float: right;
width: 240px;
background-color: white;
font-size: 17pt;
padding: 20px 12px 20px 16px;
border: 2px solid #e6e6dd;
border-bottom: 4px solid #4a4;
font-family: Georgia, Times, Serif;
}
.miniQuote * {
line-height: 17pt;
}
.twitter-box {
float: right;
width: 200px;
}
</style>
</head>
<body>
<div class="page">
<div class="header">
<div id="google_translate_element" class="language-translation"></div>
<div class="logo"><a href="index.html"> <img src="image/front-page-banner.png" alt="Specification by Example" /> </a></div>
</div><!-- header -->
<div class="menuBar">
<ul class="menu">
<li class="selectedTab"><a href="/">Home</a></li>
<li><a href="Example.html">Example</a></li>
<li><a href="Tutorial.html">Tutorial</a></li>
<li><a href="Technique.html">Hints and Tips</a></li>
<li><a href="ExtensionsAPI.html">Extensions API</a></li>
<li><a href="Extensions.html">Extensions</a></li>
<li><a href="Download.html">Download</a></li>
<li><a href="Questions.html">FAQ</a></li>
</ul>
</div><!-- menuBar -->
<div class="content">
<h1 class="subtext" style="margin: 20px 0px 20px 0px; font-size: 20pt">
Concordion is an open source tool for automating
<br />Specification by Example<span style="font-size: 15pt; vertical-align: top">*</span>
</h1>
<p style="font-size: 10pt; font-style: italic">
* There are versions for <a href="Download.html">Java</a>, <a href="dotnet/Download.html">.NET</a>, Python,
Fantom, Scala, and Ruby. [<a href="Ports.html">supported platforms</a>]
<br />
</p>
<h1 style="margin-bottom: 0px; font-size: 17pt; border-bottom : 1px dotted black; padding-bottom: 6px; width: 320px">
Key Features</h1>
<div class="twitter-box" >
<p>
<a class="twitter-timeline" data-chrome="nofooter" href="https://twitter.com/concordion" data-widget-id="526560172584341504" height="400px">
Tweets by @concordion</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+"://platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>
</p>
</div>
<ul class="keyBenefits">
<li>
<p>
<span class="keyPoint">Specifications become <em>living documentation</em></span>
Concordion specifications are so readable they can double up as system
documentation. They are written in HTML, so can be easily hyperlinked into a
navigable structure.
</p>
<p>
The specifications contain examples of behaviour which, when automated and executed against your system, are colour-coded by Concordion to show whether the examples are working. By executing these frequently, you can be confident your documentation is always up-to-date with your system.
</p>
</li>
<li>
<p>
<span class="keyPoint">Helps you to separate "what?" from "how?"</span>
Specifications that include a lot of implementation detail lock you into that
implementation. Concordion helps you to document the logic and behaviour of your
system in a way that gives you the flexibility to change the implementation
later on.
</p>
</li>
<li>
<p>
<span class="keyPoint">Purposely small command-set is simple to learn</span>
Concordion based on <em>specification by example</em> has been designed with a short learning-curve as a top priority.
Automated examples are executed as JUnit tests, which makes them easy to run and easy
to include in an existing project build.
</p>
</li>
<li>
<p>
<span class="keyPoint">Powerful extension framework for customisation</span>
While the core features are kept deliberately small, the <a href="ExtensionsAPI.html">extensions API</a> allows you to add functionality. For example, using <a href="https://github.com/concordion/concordion-excel-extension">Excel spreadsheets as specifications</a>, adding <a href="https://github.com/concordion/concordion-screenshot-extension">screenshots</a> to the output,
displaying <a href="https://github.com/concordion/concordion-logging-tooltip-extension">logging</a> information, and <a href="Extensions.html">much more</a>.
</p>
</li>
</ul>
<br />
<div class="memo">
<h1 style="width: 320px">What's special about it?</h1>
<div class="miniQuote">
<span style="font-size: 22pt">“</span>Concordion is similar to Cucumber but
focuses on readability.<span style="font-size: 22pt">”</span>
</div>
<h2>Normal language, no need for structured "given/when/then"</h2>
<p style="width: 480px">
Rather than forcing product owners to use a specially structured language for
specification by example, Concordion lets you write the specifications in normal language
using paragraphs, tables and proper punctuation. This makes them
much more natural to read and write, and helps everyone
understand and agree about what a feature is supposed to do.
</p>
<h2>Attractive output</h2>
<p style="width: 480px">
Concordion specifications are written in HTML with an attractive stylesheet
that makes them nice to read, and suitable for internal or even external
documentation. You can use HTML features such as hyperlinks and images to
make the pages even more useful.
</p>
<p>
For an example, see <a href="dist/1.5.1/spec/concordion/Concordion.html">
Concordion's own specifications</a>.
</p>
<h2>Always bang up-to-date</h2>
<p>
Concordion specifications are <b>active</b>. Behind the scenes, they are
linked to the system under test and therefore do not go out-of-date. If a
change is made to the system's behaviour then the tests associated with the
relevant specification will fail and let you know.
</p>
<p>
<img src="image/concept/AnatomyOfAnActiveSpec.png" alt="specification by example" title="Specification by Example"/>
</p>
<h2>Complex behaviours can be decomposed</h2>
<p>
Each question at the bottom of the specification links to another active
specification and so on until you have either run out of questions or
the answer is "Out of Scope". In this way, a complex behaviour can be
broken down into small, focused and easily understood requirements.
</p>
<br />
<h1>How it Works</h1>
<p>
<img style="padding-top: 24px; padding-bottom: 20px;" src="image/concept/HowItWorks.png"
alt="acceptance testing" title="Acceptance Testing"/>
</p>
<p>
Specifications with examples are written in simple HTML. Developers instrument the
concrete examples in each specification with commands (e.g. "set", "execute",
"assertEquals") that allow the examples to be checked against a real-life
system.
</p>
<p>
The instrumentation is invisible to a browser, but is processed by a Java
fixture class that accompanies the specification and acts as a buffer between
the specification and the system under test. The fixture is also a JUnit test
case, so it's easy to run and integrate into an automated build. The results of
running the examples are exported with green and red indicating successes and
failures.
</p>
<p>
Some example instrumentation:
</p>
<pre class="html">
<p>
When <span <b>concordion:set="#firstName"</b>>Bob</span> logs in a greeting
<span <b>concordion:assertEquals="greetingFor(#firstName)"</b>>Hello Bob!</span>
should be displayed.
</p>
</pre>
<br />
<h1>Technique</h1>
<p class="subtext">
With the right technique, active specifications can boost agility and make
it easier to sustain a test-driven approach.
</p>
<h2>Separating requirements from implementation helps refactoring</h2>
<p>
Hiding all the implementation-specific detail inside the Java fixture code gives
you freedom to change the internal design of your application confident that
you'll catch inadvertent changes to required behaviour. The specifications don't
change when you refactor.
</p>
<p>
One problem with unit tests is that they mix together customer requirements with
tests of internal classes. With active specifications you make a clear
distinction and it's much easier to know what's truly important and what can be
changed. The specifications describe the customer requirements whereas the test
fixtures verify internal implementation.
</p>
<h2>Specifications can be as thorough as unit tests</h2>
<p>
Specifications can cover every nuance of behaviour that is important to the
customer. There is no reason why the specifications cannot do this to the same
depth as JUnit tests. But instead of the onus being on the developer to think up
all the fine-detail tests, with active specifications, testers and analysts can
also get involved.
</p>
<h2>Specifications can be hooked in at different levels</h2>
<p>
The fixture code can be hooked in at unit, component, sub-system or system level
depending on the level of confidence required traded against speed of test
execution. The decision does not affect the specifications themselves. They just
describe the behaviour without explaining how it's implemented or how to test
it.
</p>
<h2>Agreeing details up-front allows finer control over scope</h2>
<p>
Active specifications can be used to define detailed acceptance criteria for a
story. This allows the product owner to make decisions about scope and behaviour
that would otherwise be left to the programmers. This reduces gold-plating and
allows the product owner to make conscious trade-offs of scope against
development cost. E.g. "Let's not handle this [edge case] in this iteration as
it's very unlikely to happen, and there are other stories that I want
implemented that offer more value".
</p>
<h2>Test coverage no longer relies on developer self-discipline</h2>
<p>
Automated unit tests, written by developers, are at the heart of most
traditional agile approaches. Unfortunately, because unit tests are neither
visible to management nor the product owner, there's always a feeling of
pressure to cut corners for short-term gains in development speed. In the
long-term this can be fatal for agility, but it takes constant willpower to
resist the temptation and many agile projects eventually succumb.
</p>
<p>
Driving a project with active specifications reduces this problem. Since the
specifications are written in plain language, not only are they readable and
visible outside of the development team, but they are also co-authored with the
product owner and testers. Keeping the quality high becomes a group effort.
</p>
<p>
Developers may continue to write some unit tests to drive aspects of the
internal design but the project no longer relies on them for test coverage of
external behaviour. The active specifications take over that role. Since writing
the specifications is at the core of the visible process – nothing is developed
without active specifications describing the requirements – it becomes
practically impossible to cut corners.
</p>
<p><a href="Example.html">Worked example</a></p>
<br />
<h1>Where is Concordion suitable and not suitable?</h1>
<p class="subtext">
No product is perfect for everyone and Concordion is no exception.
</p>
<h2>Concordion is not a tester-only tool</h2>
<p>
Concordion is not suitable for testers who don't have access to developers or
development skills. The specifications can be written by non-developers, but the
instrumentation and fixture code require Java programming ability.
</p>
<p>
The idea behind the product is to allow (non-developer) testers and developers
to collaborate in a way that draws on the strengths of both without needing to
step on each others toes.
</p>
<p>
It can, however, be used by developers on their own, as an alternative to
writing JUnit tests. The advantage of doing this, is that helps to separate the
two concerns: separating the requirements from the implementation.
</p>
<h2>Concordion specifications are written in HTML</h2>
<p>
Only a very small subset of HTML is needed (<p>, <table>, <b>), however, some
people may be intimidated by it or not want to write in HTML.
</p>
<p>
Sometimes developers <em>imagine</em> that testers or business analysts won't
want to learn to write HTML, but in reality it's not a problem. The crash
course, below, describes enough HTML for writing the majority of specifications
and takes most people only a few minutes to get their head round.
</p>
<p>
If for some reason, it's not possible to persuade a tester or analyst to write
in HTML, workable alternatives are for developers to sit with the analysts and
testers and "do the typing" (i.e. write the basic HTML for them) or to take or
accept notes in other formats and write them up in HTML.
</p>
</div> <!-- memo -->
<div class="crashCourse">
<div><b>Crash Course in HTML</b></div>
<p>HTML documents are written in text with special start and end tags around
items. For example:</p>
<div style="padding: 8px; background-color: white"><code><p>This is a
paragraph</p></code></div>
<p>The tag <p> signals the start of the paragraph and </p> signals the end.</p>
<p>You can nest tags.</p>
<div style="padding: 8px; background-color: white"><code><p>This is <b>bold
text</b> in a paragraph</p></code></div>
<p>When the document is displayed in a web browser, it will be rendered like
this:</p>
<div style="padding: 8px; background-color: white">This is <b>bold</b> text in a
paragraph</div>
<p>The syntax for a table is more complicated, but once you understand this,
you'll have everything you need to write tests in Concordion.</p>
<p>A table uses the following tags: <table>, <tr> (table row) , <th> (table
heading), <td> (table data). The table is expressed row by row. The first row
contains the headings, the following rows are data. For example:</p>
<pre style="padding: 8px; background-color: white; margin: 0;">
<table>
<tr>
<th>Name</th>
<th>Age</th>
</tr>
<tr>
<td>Fred Flintstone</td>
<td>35</td>
</tr>
<tr>
<td>Betty Rubble</td>
<td>27</td>
</tr>
</table>
</pre>
<p>Which produces:</p>
<table>
<tr>
<th>Name</th>
<th>Age</th>
</tr>
<tr>
<td>Fred Flintstone</td>
<td>35</td>
</tr>
<tr>
<td>Betty Rubble</td>
<td>27</td>
</tr>
</table>
</div>
<div class="memo">
<br />
<h1>Spelling of Concordion</h1>
<p>
Several people said they couldn't find this page when they searched because
they were spelling "Concordion" as concordium, concordian.
Hopefully, now we have written the words Concordium and Concordian on this page the search engines will find it even with the misspelling.
</p>
</div> <!-- memo -->
</div> <!-- content -->
</div> <!-- page -->
<div class="copyright">
<a rel="license" href="http://creativecommons.org/licenses/by/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by/4.0/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</a>.
</div> <!-- copyright -->
<script type="text/javascript" src="//s7.addthis.com/js/300/addthis_widget.js#pubid=ra-54713d647869854a" async="async"></script>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-58172036-1', 'auto');
ga('send', 'pageview');
</script>
<script type="text/javascript">
function googleTranslateElementInit() {
new google.translate.TranslateElement({pageLanguage: 'en', layout: google.translate.TranslateElement.InlineLayout.SIMPLE, gaTrack: true, gaId: 'UA-58172036-1'}, 'google_translate_element');
}
</script>
<script type="text/javascript" src="//translate.google.com/translate_a/element.js?cb=googleTranslateElementInit"></script>
</body>
</html>