Test first!
0 likes358 views
The document discusses test-driven development (TDD). It explains that TDD is a software development technique where test cases are written before code to validate requirements. The TDD process involves writing a test case for new functionality, seeing the test fail, then writing the code to pass the test and refactoring if needed. TDD helps improve code quality, catch bugs early, and clarify requirements and design through executable tests. The document outlines the TDD workflow and best practices like keeping tests and code separate, focusing on test isolation, and using test doubles. It also compares TDD to related techniques like unit testing, integration testing, and behavior-driven development.
Test first!
- 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 modify the software behavior
- 7. The D in the Middle • You let the tests to 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
- 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 (or other tests) to design the software • Working on a better design it's possible to improve the quality of the software
- 10. Small and Testable • Methods and functions should be simple in order to be testable • Generally speaking, 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
- 11. Test Double The general name for objects used to replace real component servers for testing purposes • Dummy, an object without any specific implementation • Stub, an object with interface or minimal implementation • Spy, a step up from stub because it records which object used itself • Fake, an object with a more complex implementation • Mock, an object dynamically created by a library (e.g. http://sinonjs.org)
- 12. Common Sentences • “It costs too much time, we’d better fix these bugs first” • “Our system is too big for unit tests” • “We just ought to be more careful not to introduce bugs, that will help us a lot” • “Our system is not suited for unit tests” • “We have a QA-team that will detect errors”
- 13. TDD and QA • Test driven development is not a quality assurance method • Most people associate "testing" with "quality assurance" • With TDD you write code using tests as a tool, the QA team searches bugs using the same tests as a tool
- 14. Best Practices
- 15. 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
- 18. 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 • Try to prioritize them (e.g. test first user creation than login!)
- 19. Write the Assertion First Determine how the specification (i.e. the test) is going to be validated
- 22. Glossary • Unit, the smallest piece of code software that can be tested in isolation • Assertion, it's a predicate that states the programmer’s intended state of a system • Integration test, a test that go outside the current process interacting with something else • Interaction test, a test on the way that objects work together • Fake, any stand-in object that's used instead of the real thing • Stub, a stand-in object that provides a dependency required by the code under test • Mock, a simulated object that mimics a specific behavior
- 23. Individual Units • Source code is tested to understand if it can be used by other part of the software • Test cases are separated and independent by each other • Method stubs, mock objects and fakes data can be used to run the tests in isolation
- 24. Benefits • Helps finding problems early • Facilitates changes (i.e. regressions testing) • Simplifies integration • Improves the documentation
- 25. Limitations • Unit testing will not catch every error in the program • Integration errors will be not catch because the test itself by definition test only the unit • Code coverage doesn't prove the software is working • It's time consuming
- 26. Common Challenges • Setting up realistic and useful tests • Testing asynchronous code • Testing private methods • Writing flexible tests • Effective names
- 27. Usefulness • Define relevant initial conditions • Tests have to exercising the code in a realistic context • Avoid unnecessary preconditions • Don’t unit-test configuration settings
- 28. Flexibility • Tests should never over specify the behavior of the target code • Tests should never test more than once the same code (i.e. don't repeat yourself!) • Always use only data relevant to a particular test in the test • Consider always how to pass input data (e.g. Builder pattern)
- 29. Async Code • The main issue is to keep the test blocked until the async code has been executed • You can repeatedly polling the target system for a state change (i.e. Sampling) • You can use an event-based assertion that waits for an event by blocking on a monitor until it gets notified or times out (i.e. Listening)
- 31. Naming • The name should clearly indicate the tested feature • The test name should indicates what the unit does not what the unit is • The test name should say something about the motivation for the scenario • Use the TestDox convention where each test name reads like a sentence
- 33. Key Features • ATDD is a practice in which the whole team collaboratively discusses requirements acceptability • ATDD, like TDD, involves creating tests before code • The acceptance tests then become like executable requirements
- 34. Expected Benefits • ATDD results in applications designed to be easier to test • ATDD favors the creation of interfaces specific to functional testing • ATDD clarify to all the team members which are the customer expectations
- 36. Testing Pyramid
- 37. Software Requirements As a <role> I want to <goal> so that <motivation> • User stories are the central axis around which a software project rotates • User stories express requirements in terms of The Role, The Goal, and The Motivation • User stories aren’t exhaustive requirements specifications
- 38. Acceptance Criteria • A set of conditions the requirement must fit in to be considered done • It's the result of a conversation with the customer (or product owner) • It's a way to describe the tests a requirement should pass
- 39. Writing Acceptance Criteria • An acceptance criteria should contain an Actor, a Verb and an Observable Result • An acceptance criteria describe a pre-condtion when an actor should perform an action and obtain the expected result (e.g. mandatory fields) • An acceptance criteria should be also identify performances expectations
- 41. ATDD Cycle
- 48. Sign of Use • Significant portion of "functional documentation" is in the form of User Stories augmented with executable scenarios or examples • Instead of referring to "tests", team members will prefer the terms "scenario" and "specification" • Tests are a mean to define the specifications of the behavior of a Module
- 49. Common Issues • BDD requires familiarity with a greater range of concepts than Unit Testing does • BDD don't requires at the beginning particular tools or programming languages, and is primarily a conceptual approach • BDD requires a different development cycle
- 50. BDD Cycle
- 51. Context and Specifications • Sets of related observations (tests) will be gathered into contexts • Contexts aren’t simply arbitrary groupings, they represent cohesive and consistent circumstances that software modules can be found in • Specifications are the tests written using a BDD testing framework
- 52. Effective Scenarios • Capture a summary scenario • Identify actors and their goals • Sentences should be in sequential order • Each sentence should have an actor performing an action
- 54. Tests Anatomy
- 56. ATDD Tests
- 59. Jasmine Provides • A natural BDD syntax for organizing the test logic • Asynchronous testing support • Mocks object • Spies • Custom matchers
- 64. Specs.html It contains four script tags: • The first section includes the Jasmine test runner files • In the next two sections, you reference your JavaScript code to be tested as well as the tests • The fourth runs the tests
- 66. Grunt • A JavaScript task runner • A project scaffolding tool • Use it to automate common task execution execution
- 67. • Configurable plugins such as require.js, handlebar, jasmine, etc. 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
- 70. Links • http://msdn.microsoft.com/en-us/magazine/cc163358.aspx • http://guide.agilealliance.org/guide/atdd.html • http://guide.agilealliance.org/guide/acceptance.html • http://www.codemag.com/article/0805061 • http://www.slideshare.net/nashjain/acceptance-test-driven- development-350264 • http://testobsessed.com/wp- content/uploads/2011/04/atddexample.pdf • http://programmers.stackexchange.com/questions/135218/what- is-the-difference-between-bdd-and-tdd • http://www.slideshare.net/emwendelin/test-your-javascript
- 71. My Latest Book
- 72. What's Next