Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduction to Unit Testing, BDD and Mocking using TestBox & MockBox at Into the Box 2018


Published on

Uma Ghotikar

Published in: Technology
  • Login to see the comments

Introduction to Unit Testing, BDD and Mocking using TestBox & MockBox at Into the Box 2018

  1. 1.
  2. 2. 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
  3. 3. • 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?
  4. 4. 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
  5. 5. 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
  6. 6. TDD – Test Driven Development Test Driven Development mantra: “red/green/refactor” • red means fail • green means pass • and then we refactor, if any
  7. 7. TDD – Example `concatenate()`: Test
  8. 8. TDD – Example `concatenate()`: Code
  9. 9. TDD – Example `concatenate()`: Test Result
  10. 10. 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
  11. 11. 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
  12. 12. 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?
  13. 13. BDD – Behavior Driven Development • Dan North: • 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
  14. 14. BDD – Behavior Driven Development
  15. 15. Story Framework • Story: We will start with a story • Scenario: We will create scenarios from it • Specification: We will then code our specifications
  16. 16. 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]
  17. 17. 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
  18. 18. 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 }); }); }); });
  19. 19. 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
  20. 20. BDD - Life Cycle Methods, Suites, Tests and Specs
  21. 21. BDD - Life Cycle Methods, Suites, Tests and Specs
  22. 22. BDD – Example `concatenate()`: Test
  23. 23. BDD – Example `concatenate()`: Test Result
  24. 24. 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:
  25. 25. 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.
  26. 26. Examples • Functions with no dependencies / interactions • Functions with dependencies / interactions
  27. 27. 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
  28. 28. BDD – Example `division()`: Test
  29. 29. BDD – Example `division()`: Code
  30. 30. BDD – Example `division()`: Test Result
  31. 31. Functions with dependencies / interactions
  32. 32. Functions with dependencies / interactions Styles of testing • Classic: Prefers sociable tests • Mockist: Insists upon solitary tests
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. Mocking – Example: Interaction with File Systems Code Demo
  37. 37. How to mock a Query?
  38. 38. How to mock a Query?
  39. 39. Interaction with External APIs – Google Geocoding API • 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
  40. 40. Interaction with External APIs – Code
  41. 41. Interaction with External APIs – Mock Example
  42. 42. Resources • • • • • • misconceptions/ • • • • • • • • difference-between-faking-mocking-and-stubbing • baby/blob/master/Mock%20It%20Baby.pdf • smell-944a70c90a6a • • you-shouldnt-bother.html • slides-at-nvcfug •
  43. 43. Final Thoughts
  44. 44.