TDD is a software development technique where test cases are written before production code to specify desired behavior. It involves writing a test that fails, then producing the minimum amount of code to make it pass, and refactoring the code to improve design. This process helps improve code quality, catch bugs early, and drive code design. BDD is a style of TDD that focuses on writing tests in a natural language format describing desired behavior. Frameworks like Jasmine provide tools for writing BDD-style tests in JavaScript.

5. What is TDD
• It's a development technique based on a short development
process
• It's a way to deeply analyze the expected behavior of a
software
• It's a mean to improve the quality of the source code
• It's a practice to enhance the documentation of a software
• It's a way to ensure a safer way to change the software design

6. TDD and Unit Tests
Unit tests can be written before writing the code,
after the code has been written or during the development
• Unit Testing refers to what you are testing, TDD to when you are
testing
• Unit Testing means, well, testing individual units of behavior

7. The D in the Middle
• You let the tests drive you
• The tests tell you what to do, what to do next, what's done
• The tests are the skeleton of the API design

8. TDD Workflow
TDD is writing a test which will fail, then writing the minimum
amount of code required to make it run, then refactoring the code to
make it clean

9. The D at the End
• It's supposed to mean development but originally was supposed
to mean design
• Test Driven Design is the discipline of using Unit Testing to
design the software
• Working on a better design it's possible to improve the quality of
the software

11. Small and Testable
• Methods and functions should be simple in order to be testable
• Even better, the code needed to satisfy a test is usually a very
small chunk of code
• As a result the public API are simple and easy to maintain

13. Refactoring
Use this catalog http://goo.gl/Fo9VzV as a
reference to existing refactoring techniques
• Restructuring existing code altering (or improving) its internal
structure
• Don't change its external behavior (or design)
• It should happen only when the all tests are passing

14. Why Refactoring?
• To improve the performances
• To clean up the code
• To improve the code reusability and maintainability
• To improve the code readability
• To remove duplicated code

15. TDD + Refactoring
• TDD is not mainly a testing strategy, but a design strategy
• Writing tests first it's possible to get a better decoupled design
• A better decoupled design is easier to refactor too

17. TDD and Bugs
• Never trust blindly developer's tests
• TDD is not a replacement of Quality Assurance
• Tests cannot catch all the bugs, functional testing is required
too

18. TDD Takes Too
Much Time
• Let developers to save time preventing and identifying
regression issues
• Writing failing tests first, developers will pinpoint the root of the
problem more effectively
• Small problems will be identified faster

19. Too Complex to
Learn
• Not so much, embracing change and the unknown can be
scaring for anyone
• Writing tests once the code has been written is even more
complex
• Writing small tests before you avoid to test a huge app later and
all at once

20. The App is not
Designed
• Requiring to write unit tests before the production code
TDD drives to a better task focus
• Being focused on a specific task let developers to better
understand it
• A deeper focus and a better understanding drive to a better
design

21. Disadvantage of
TDD

22. More Coding
• TDD means it's not allowed to skip the tests so developers have
to write more code
• The amount of code to maintain is b

23. Increased
Complexity Using
Mocks, DI and IoC
• Most of the time developers have to create mock data to run
tests
• When using mocks developers start to apply the dependency
injection (i.e. DI) pattern
• In order to use complex mocks data the Inversion of Control
technique is ueused

24. Changing Issues
• When the software start to grow up a change impacts also a
great number of tests
• Developers need more time to address changes

25. Pragmatic TDD

26. Write Valuable
Tests
• A test is valuable when describe a condition to satisfy based
upon software requirements
• Don't write tests just to cover all the source code, write the tests
following a strategy

27. Choose the Right
Tests
• Acceptance tests
• Smoke tests
• Integration tests
• Performance and load tests

29. Assertions
• Assertions are statements that perform an actual check on the
software’s output
• A single function called assert is enough to express any check
• TDD libraries have many assert functions for specific needs
(assertFalse, assertEqual,s, etc.)
• A single assert should be used in each test
• An assert failure should add a clear message to the test logs

30. Test Double
Objects the test code creates and passes to the SUT to replace real
dependencies:
• dummy, object never used but needed to fill some required
parameter
• fake, object that implements the required functionality in a way
useful only in testing
• stub, object that can return predefined values to the tested
software
• mock, object that expects to be used a specific number of times
returning predefined values

31. Integration Testing
• A mid-level testing activity that verifies a certain set of modules
work correctly together
• Integration tests are like unit tests without using test doubles
for some dependencies

32. Fixture
• A particular environment that must be set up before a test can
be run
• It generally consists of setting up all test doubles and
dependencies for the tested software

33. Source & Tests
Separation

34. Pick the First Test
• Carefully read the requirements and eventually split them if
needed
• Choose a requirement and write a list of tests for this
requirement
• Select a test that is atomic and well isolated

35. Write the Assertion
First

36. First Time Failure
• How to test something that doesn't exist?
• By adding methods or functions to test developers start to
design first the code

38. Why is Important?
• JavaScript is so flexible that some rules help to improve the
quality of the code
• Forces developers to refactor the code and to keep the functions
small and simple
• Helps to prevent common regressions issues
• Is a way to bring the language itself to a more enterprise level
Untestable
JavaScript

39. var MyModule = (function(){
_privateFunc = function(){};
return {
publicFunc: _privateFunc
};
});
addEventListener('click', myEventListener);
• Don't include all the code in a closure without exposing a public
API
• Don't use anonymous event handlers, use instead named
functions

40. Model View
Presenter

41. Qunit
• Support for testing asynchronous code
• Non standard (and non intuitive) syntax
• Eight assertions available
• Well integrated with jQuery (actually maintained by the jQuery
team)
• Documented API http://api.qunitjs.com/

42. Phantom.js
• Command Line based
• Can use report runners that get tied in to CI environments
• Support for screen capture
• Support for testing asynchronous code
• Very detailed wiki https://github.com/ariya/phantomjs/wiki

43. Buster.js
• Run tests from browser or headless with PhantomJS
• Supports NodeJS testing
• Don't need to run server/clients on development computer (no
need for IE)
• Supports multiple JavaScript test frameworks

44. Karma.js
• Run tests from browser or headless with PhantomJS
• Option to launch, capture, and automatically shutdown browsers
• Write tests xUnit or BDD style
• Supports multiple JavaScript test frameworks
• Extend it to wrap other test-frameworks (Jasmine, Mocha, QUnit
built-in)

45. Even More
• Mocha.js
• JsTestDriver
• YUI Yeti
• Casper.js
• Etc.

46. Browserstack and
TDD
• Integrated with Jenkins, Bamboo and other CI tools
• Support for testing tolls like Yeti, TestSwarm, BunyIP, TestEm

48. Behavior Driven
Development
• Help the developers devising the system identify appropriate
tests to write
• Help to write tests that reflect the behavior desired by the
stakeholders
• Uses a "Ubiquitous Language" that can be understood by both
the developer and the customer.

50. Differences
• BDD begins with a B and TDD begins with a T (Mike Brown)
• BDD provides a new vocabulary and thus focus for writing a unit
test
• Basically it is a feature driven approach to TDD

51. Jasmine
Ready to meet a super cool lady? :)

52. WAT ?!?
It is a behavior-driven testing framework for JavaScript programming
language. It’s a bunch of tools that you can use to test JavaScript
code
• Tests should be sentences
• Tests should be very small

53. Sample Test
describe("Hello world", function() {
it("says hello", function(){
expect(helloWorld()).toEqual("Hello world!");
});
});

54. Suite
• describe(" Hello world"... is what is called a suite
• The name of the suite (“ Hello world” in this case) defines a
component of your application

55. Spec
• Inside of that suite (technically, inside of an anonymous
function), is the it() block
• This is called a specification, or a spec for short

56. Matcher
• In this case, you’re testing if helloWorld() does indeed return
"Hello world!"
• This check is called a matcher

57. toBeDefined
&
toBeUndefined

58. toBeTruthy
&
toBeFalsy

59. toBeLessThan
&
toBeGreatherThan

60. toBe

61. toEqual

62. toMatch

63. toBeCloseTo

64. toBeNaN

65. toBeNull

66. toContain

67. toThrow

68. Expectations

69. Custom Matchers
beforeEach(function () { this.addMatchers({
theNameOfTheMatcher: function(){
// The code to be executed by the matcher
}
});
});

70. beforeach &
aftereach
They allow you to execute some code before and after each spec

71. Async Calls
it(" does an asynchronous call", function() {
exampleAsyncCall( function( response) {
expect( response).toContain(" something expected");
done();
});
});

72. Even more...
Refer to the online wiki https://github.com/pivotal/jasmine/wiki

74. • A JavaScript task runner
• A project scaffolding tool
• Use it to automate common task execution execution
• Configurable plugins such as require.js, handlebar, jasmine, etc.

75. Using Grunt
• First of all install grunt command line tool npm install -g grunt-
cli
• Most grunt-init templates will automatically create a
package.json file
• Install grunt an the plugins npm install grunt --save-dev
• Install the jasmine plugin npm install grunt-contrib-jasmine --
save-dev

76. The Grunt.js File

78. Default Project

79. Run and Compile

80. The benefits

81. Questions &
Answers
Here a slide to help me to break down the distance between me and
the audience