Uma Ghotikar

2. https://www.linkedin.com/in/umaghotikar/
https://twitter.com/umaghotikar

3. Agenda
• Unit Testing – What, Why?
• Guidelines
• TDD and BDD
• Story Framework
• TestBox
• Given – When – Then syntax
• General structure for writing Unit Tests
• Mocking – What? Why?
• MockBox
• Demo examples
• Resources

4. • Unit Testing is a level of software testing where individual units/ components
of a software are tested
• A unit is a smallest piece of functionality that can be tested in isolation
• Unit tests are low-level, small scope and fast
What is Unit Testing?

5. Why?
• To validate that each unit of the software performs
as designed
• Development and refactoring is faster
• Increases confidence in changing/ maintaining code
• Provides instant feedback
• Modular code becomes more reusable
• Can expose high coupling
• Less cost of fixing a defect
• Debugging is easy - Easy to locate the bug
• Acts as a safety net
• Better quality code and more stable code

6. Unit tests must be
• Fast
• Isolated
• Independent
• Robust
• Maintainable
• Purposeful
• Automated
• Name tests properly
Guidelines for writing good unit tests
Unit tests should be
• Fast
• Isolated
• Independent
• Robust
• Maintainable
• Purposeful
Code should be
• Keep the units small
• High cohesion and low coupling

7. TDD – Test Driven Development
Test Driven Development
mantra:
“red/green/refactor”
• red means fail
• green means pass
• and then we refactor, if
any

8. TDD – Example `concatenate()`: Test

9. TDD – Example `concatenate()`: Code

10. TDD – Example `concatenate()`: Test Result

11. TDD – Test Driven Development
• TDD is a technique for building software that guides software development by
writing tests – so we write the tests first and then we write the code
• It was developed / rediscovered by Kent Beck in the late 1990's as part of Extreme
Programming
• Focuses on CFCs and methods

12. TDD – Test Driven Development
TDD helps to
• Get immediate feedback
• Create tests before rather than after
• Create some documentation
• Verify that the source code compiles and executes
• Assist in assuring that the code should be as unit testable as possible

13. What TDD doesn’t do / Limitations of TDD?
• Very much developer oriented
• Tedious as we always have to test methods
• Refactoring is a pain
• It is not about verifying software requirements – since it only focuses on functions and
verifies that functions are working correctly
• Neither verifies stakeholders' expectations nor expresses that requirements are satisfied
Questions:
• Where to start?
• What to test?
• What not to test?

14. BDD – Behavior Driven Development
• Dan North: https://dannorth.net/introducing-bdd/
• BDD is a software development process that emerged from TDD. It is an evolution of TDD
and has roots in TDD
• Ubiquitous Language: BDD is largely facilitated through the use of a simple domain
specific language using natural language constructs (e.g., English-like sentences) that can
express the behavior and the expected outcomes
• Focuses on stories or requirements rather than on functions
• BDD focuses on what a system should do and not on how it should be implemented
• Better readability
• Verifies that software works but also that it meets customer expectations

15. BDD – Behavior Driven Development

16. Story Framework
• Story: We will start with a story
• Scenario: We will create scenarios from it
• Specification: We will then code our specifications

17. Story Framework
Story template:
As a [role]
I want [feature]
So that [benefit]
Scenarios:
Given [context]
And [some more context]
When [event]
Then [outcome]
And [another outcome]

18. Stories to Scenarios
As an application user
I want to have publish file functionality
So that file gets published
File gets successfully copied from source (unpublished folder) to destination
(published folder) and we delete the file at the source path
Given: I have source path
AND destination path
AND file to be copied
When: I click the publish button
Then: File is copied from source to destination
AND file at source is compared with the file at destination
AND file at source is deleted
Story
Scenario

19. Scenarios to Specification in TestBox
describe("file gets successfully copied from source to destination and we delete the file at source path", function(){
given("source path, destination path and file to be copied", function() {
when("I click the publish button", function() {
then("file should be copied from source to destination", function() {
//some code and expect statement
});
then("file at source should be compared with the file at destination", function() {
//some code and expect statement
});
then("file at source should be deleted", function() {
//some code and expect statement
});
});
});
});

20. What is TestBox?
• TestBox is a next generation testing framework for
ColdFusion (CFML)
• It is based on BDD for providing a clean obvious
syntax for writing tests
• With TestBox, we are bringing in the Syntax for BDD
into our unit testing
• It supports xUnit style of testing and MXUnit
compatibilities
• It contains not only a testing framework, runner,
assertions and expectations library but also ships
with MockBox

21. BDD - Life Cycle Methods, Suites, Tests and Specs

22. BDD - Life Cycle Methods, Suites, Tests and Specs

23. BDD – Example `concatenate()`: Test

24. BDD – Example `concatenate()`: Test Result

25. Given – When – Then
• `given`: is the state of the world before
you begin the behavior you are
specifying in this scenario. You can think
of it as the pre-conditions to the test.
• `when`: is the behavior that you are
specifying / event trigger
• `then`: is the changes you expect due to
the specified behavior / postcondition
which must be verified as the outcome
of the action that follows the trigger
The essential idea is to break down writing a
scenario (or test) into three sections:

26. Structure for writing Unit Tests
Four Phase Test
• Setup (Given)
• Exercise (When)
• Verify (Then)
• Teardown (Clean up)
Arrange – Act – Assert
• Most unit tests don’t need teardown. Unit tests (for the bulk of the system) don’t
talk to external systems, databases, files, etc., and Arrange-Act-Assert is a pattern
for unit tests.

27. Examples
• Functions with no dependencies / interactions
• Functions with dependencies / interactions

28. Functions with no dependencies / interactions
• Isolated and independent functions
• Simple to unit test
• Examples:
• concatenate()
• division() – Expecting Exceptions: Make
sure to exercise all code paths

29. BDD – Example `division()`: Test

30. BDD – Example `division()`: Code

31. BDD – Example `division()`: Test Result

32. Functions with dependencies / interactions

33. Functions with dependencies / interactions
https://martinfowler.com/bliki/UnitTest.html
https://leanpub.com/wewut
Styles of testing
• Classic: Prefers sociable
tests
• Mockist: Insists upon
solitary tests

34. Mocking
• Mocking is creating objects that simulate the behavior of real objects
• A mock is a test double that stands in for real implementation code during the unit
testing process

35. Why to Mock? What can we mock?
Why?
• To isolate the behavior of the SUT
• To be able to develop when the collaborators are not yet built / unavailable
• To be able to control data and expectations
• When collaborator’s behavior is hard to control / impractical to incorporate into
the unit test
What?
• Methods, Components, Properties, API calls, data, filesystems, etc

36. What is MockBox?
• Mocking Framework
• It is a companion package to TestBox
• It gives us advanced mocking/stubbing
capabilities
• It gives us ability to create mock objects
• It has mocking methods and verification
methods available

37. Mocking – Example: Interaction with File Systems
Code Demo

38. How to mock a Query?

39. How to mock a Query?

40. Interaction with External APIs – Google Geocoding API
https://developers.google.com/maps/documentation/geocoding/intro
• Address: 1600 Amphitheatre Pkwy, Mountain View, CA 94043
Scenario: Location pins are to be plotted on the Google map using Google Geocoding API
Given: A good / valid address
When: `demoMap()` function is called
Then: the good geocode is returned and location pin is plotted on
the Google Map

41. Interaction with External APIs – Code

42. Interaction with External APIs – Mock Example

43. Resources
• https://testbox.ortusbooks.com/
• https://en.wikipedia.org/wiki/Unit_testing
• https://en.wikipedia.org/wiki/Test-driven_development
• https://martinfowler.com/bliki/UnitTest.html
• https://martinfowler.com/bliki/TestDrivenDevelopment.html
• http://blog.acntech.no/unit-testing-myths-and-
misconceptions/
• https://en.wikipedia.org/wiki/Behavior-driven_development
• https://dannorth.net/introducing-bdd/
• https://dannorth.net/whats-in-a-story/
• https://martinfowler.com/bliki/GivenWhenThen.html
• http://xunitpatterns.com/Four%20Phase%20Test.html
• http://xp123.com/articles/3a-arrange-act-assert/
• https://martinfowler.com/articles/mocksArentStubs.html
• https://stackoverflow.com/questions/346372/whats-the-
difference-between-faking-mocking-and-stubbing
• https://github.com/gratzc/mock-it-
baby/blob/master/Mock%20It%20Baby.pdf
• https://medium.com/javascript-scene/mocking-is-a-code-
smell-944a70c90a6a
• https://en.wikipedia.org/wiki/XUnit
• http://blog.adamcameron.me/2013/10/unit-testing-why-
you-shouldnt-bother.html
• https://www.ortussolutions.com/blog/testbox-bdd-video-
slides-at-nvcfug
• https://leanpub.com/wewut

44. Final Thoughts

45. https://www.linkedin.com/in/umaghotikar/
https://twitter.com/umaghotikar