This presentation has been prepared by Oleksii Prohonnyi for internal JS team meeting for improving skills of developers.

1. INTRODUCTION TO
* DRIVEN DEVELOPMENT
_by Oleksii Prohonnyi

2. HISTORY

4. Unit testing history
 First time mentioned in "The Mythical Man-Month"
(1975) by Fred Brooks.
 Described in detail in "The Art of Software Testing"
(1979) by Glenford Myers.
 In 1987 IEEE adopted special standard of software unit
testing.
 Kent Beck set out the main ideas of TDD in his book
"Extreme Programming Explained“ (1999).

6. TDD

8. Test-driven development (TDD)
Software development process that relies on the repetition
of a very short development cycle: first the developer writes
an (initially failing) automated test case that defines a
desired improvement or new function, then produces the
minimum amount of code to pass that test, and finally
refactors the new code to acceptable standards. Kent
Beck, who is credited with having developed or
'rediscovered' the technique, stated in 2003 that TDD
encourages simple designs and inspires confidence.
<Wikipedia.org>

9. Test-driven development cycle
1. Add a test
2. Run all tests and see if the new one fails
3. Write some code
4. Run tests
5. Refactor code
6. Repeat

12. TDD
BEST PRACTICES

13. Keep the unit small
For TDD, a unit is most commonly defined as a class, or a
group of related functions often called a module. Keeping
units relatively small is claimed to provide critical benefits,
including:Described in detail in "The Art of Software
Testing" (1979) by Glenford Myers.
 Reduced debugging effort – when test failures are
detected, having smaller units aids in tracking down
errors.
 Self-documenting tests – small test cases are easier to
read and to understand.

14. Test structure
Effective layout of a test case ensures all required actions
are completed, improves the readability of the test case,
and smooths the flow of execution.
1. Setup
2. Execution
3. Validation
4. Cleanup

15. Individual best practices
 Separate common set up and teardown logic into test
support services utilized by the appropriate test cases.
 Keep each test oracle focused on only the results
necessary to validate its test.
 Design time-related tests to allow tolerance for execution
in non-real time operating systems.
 Treat your test code with the same respect as your
production code. It also must work correctly for both
positive and negative cases, last a long time, and be
readable and maintainable.

16. Practices to avoid
 Having test cases depend on system state manipulated
from previously executed test cases.
 Dependencies between test cases. A test suite where
test cases are dependent upon each other is brittle and
complex.
 Testing precise execution behavior timing or
performance.
 Building “all-knowing oracles.” An oracle that inspects
more than necessary is more expensive and brittle over
time.

18. TDD
JAVASCRIPT TOOLS

19. Karma
JavaScript test-runner built with Node.js, and meant for unit
testing.
Created by AngularJS team.
http://karma-runner.github.io

22. Protractor
End-to-end test framework for AngularJS applications.
Uses Selenium Web Driver to drive tests.
Created by AngularJS team.
http://angular.github.io/protractor/

25. See more
 BusterJS
 TestSwarm
 SinonJS
 Qunit
 Intern

26. BDD

28. Behavior-driven development (BDD)
Software development process that emerged from TDD.
Behavior-driven development combines the general
techniques and principles of TDD with ideas from domain-
driven design and object-oriented analysis and design to
provide software development and management teams
with shared tools and a shared process to collaborate on
software development.
<Wikipedia.org>

29. What’s wrong with TDD?
Behavior-driven development was developed by Dan North
as a response to the issues encountered teaching test-
driven development:
 Where to start in the process
 What to test and what not to test
 How much to test in one go
 What to call the tests
 How to understand why a test fails

30. BDD philosophy
 Unit test names be whole sentences starting with the
word "should" and should be written in order of business
value.
 Acceptance tests should be written using the standard
agile framework of a User story: "As a [role] I want
[feature] so that [benefit]".
 Acceptance criteria should be written in terms of
scenarios and implemented as classes: Given [initial
context], when [event occurs], then [ensure some
outcomes].

32. BDD
JAVASCRIPT TOOLS

33. Cucumber
Test-runner tool built with Ruby, it runs automated
acceptance tests written in a BDD style.
Uses Gherkin (a "pseudonatural" language) for test
scenarios definition.
https://cukes.info/

36. Mocha
Mocha is a feature-rich JavaScript test framework running
on node.js and the browser.
http://mochajs.org/

39. See more
 Jasmine
 Concordion
 Kahlan
 Behat
 Intern

40. References

41.  "Test Driven Development: By Example" (Kent Beck)
 "Refactoring: Improving the Design of Existing Code"
(Martin Fowler)
 "Test-Driven JavaScript Development" (Christian
Johansen)
 "The Cucumber Book: Behaviour-Driven Development
for Testers and Developers" (Matt Wynne, Aslak
Hellesøy)
 agiledata.org
 dannorth.net

43. Oleksii Prohonnyi
facebook.com/oprohonnyi
linkedin.com/in/oprohonnyi