ITB 2023 10 Techniques for writing easy yet stupidly thorough unit tests_Dan Card.pdf

Testing has become essential in software development, offering benefits in debugging and deployment. This session will guide attendees from basic function tests to advanced techniques like mocking and testing API interactions. Examples will use ColdBox, but most techniques are applicable to other frameworks. The goal is to demystify testing and provide practical skills for effective implementation.

1. Session
10 Techniques To Writing Easy Yet Stupidly
Thorough Unit Tests
LED BY
Dan Card
Use ColdboxCreate App and `Install ninja_testing` from CommandBox

2. Dan Card
SPEAKER AT ITB2023
Dan Card is a Senior Developer at Ortus Solutions who find pictures of
people with their chin in their hands somewhat pretentious.
•Lives just north of Boston
•Been using CF since 2004
•Has developed a love of testing
in the past few years
•Sometimes uses frozen Zoom
pictures as headshots

3. Very VeryQuick “Philosophy”
There are several types of testing, each with its own goals
•Functionalvs Non-Functional–Testing the app vs things “around” the app such as performance and load
•Automatedvs Manual–Automated is done by software and the results reported or a is allowed to continue.
Manual is done by a person

4. Some Types of Non-Functional Testing
Very VeryQuick “Philosophy”
Performance
How quick and responsive is the app under “normal” load ?
Load Testing
Can the overall system handle peak loads?
Usability Testing
What is the quality of the user’s experience?
Security Testing
Does the application secure and handle data correctly? Examples: Scanning and Penetration testing,
code reviews, Fixinator

5. Types of Automated Functional Testing
Very VeryQuick “Philosophy”
Unit Testing
Testing One method Only
Integration Testing
Testing How Methods Interact
Closed –Box Testing
Test the entire system, usually
from the browser or interface

6. Testing Type Overview
Somewhat Quick-ishPhilosophy
Functional Non-Functional
Automated•Closed –Box -(cf)Selenium,
(cb)Playwright
•Integration –Testbox
•Unit –Testbox
•Performance –Load timings,
getTickCount()
•Load –Jmeterand many others
•Security –OWASP standards,
Fixinator
Manual •What most of us do and call it a
day •Usability
•Security

7. Unit Tests vs Integration / Closed - Box Tests
No really, this is the end of the Philosophy part
•Tests what reaches the front end.
•Difficult or “expensive” to verify “fire
and forget” actions.
•Side Effects
•DB accessed
•HTTP Called
•Emails sent (unless handled)
•Stats recorded
•No Side Effects
•Designed to run anywhere
•Can be more complicated to
write
•Debatably should be the
majority ofyour testing.
There is a place for each type of testing since each has a role to play with some but certainly not 100% overlap.
UnitIntegration
LET’S GET STARTED!!!

8. Our Project
Let’s Get To It!
Welcome to Ninja!
•A ninja gym isn’t so much martial arts as a
massive obstacle course focusing on
balance, climbing, and swinging
•Our Gym assess on 6 skills.
•Students start at level 0 and move up
•When all skills reach a level, the student
levels up (i.e.all skills to 1 = student at
level 1).
•The skill levels are color coded to make
reading easier.
•When a student levels up, they receive a
free book from the gym.
The site is mostly built and working.
It’s our job to unit test it.
Let’s Get Started!!!
`Install ninja_testing` from CommandBox

9. Something In, Something Out
Function: Students.obtainStyle()
This is the core of most testing and the simplest to set up.
Some Basics:
•How do you create tests?
•How do you run tests?
•Where do you create tests?
•
What is a `describe` function? –A suiteof tests
•What is an `it` function? – A spec
•What is an expectation?
•Expectation vs Assertion
Number 1:
Purpose: Accepts a students’ level and returns the correct color coding

10. Something Complex In, Something Complex Out
Mock Data is when we use made up data to test the ins and outs of a method
Mock Data is part of TestBoxbut can also be used outside of it
New Concepts:
-Complex Mock Data
-Looping over expectations
-The `beforeEach()` method (varScoping )
Purpose: Uses a submitted id and the filter() function to find the selected
students
Function: Students.findStudentLevel()
Number 2:

11. Mocking Methods
Mocking is the process of substituting in “fake” methods for the methods your testing object calls.
Key Point: You don’t mock the method you’re testing, You might mock everything around it though.
Common techniques:
-counting how often a method is called
Purpose: Creates the table data used in the interface
Function: Students.createStudentArray()
Number 3:

12. Reacting to Returns
Frequently, our methods need to make decisions based on what is returned from a method it calls. When we
mock a method, we can dictate what it returns and therefore control what triggers what the method we’re
testing
Purpose: Creates the table data used in the interface
Function: Students.createStudentArray() (Part 2)
Number 4:

13. Satisfactory Signatures
We’ve set up what our mocked methods are returning. Can we also test what each method is sending?
•_MOCKCALLLOGGERS
Purpose: Creates the table data used in the interface
Function: Students.createStudentArray() (Part 3)
Number 5:

14. Querulous Queries
Why?
•Forces us to slow down
•Attention to detail
•Let’s us know if the
knuckleheads we work with
changed anything
•Students.obtainStudentData()
One of the main “tenets” of unit tests is that they can be run without any side effects. Simply put, with no
outside access. That includes queries, http requests, file reads and writes and so on. However, these things are
rampant through all ofour code? How do we test.
-Pull them out
-Mock them
Number 6:

15. Querulous QB Queries
Why?
•Forces us to slow down
•Attention to detail
•Let’s us know if the
knuckleheads we work with
changed anything
•Students.obtainStudentData()
One of the main “tenets” of unit tests is that they can be run without any side effects. Simply put, with no
outside access. That includes queries, http requests, file reads and writes and so on. However, these things are
rampant through all ofour code? How do we test.
-Pull them out
-Mock them
Number 6a:

16. Precise Properties
•Lorem ipsum dolor
•Consectetur adipiscing elit
•Sed do eiusmod tempor
•Incididunt ut labore
•Lorem ipsum dolor
•Consectetur adipiscing elit
•Sed do eiusmod tempor
•Incididunt ut labore
The components in which our methods reside have properties. These can be values which our methods use or
components on which our methods can call methods. In models, we can easily mock these values and
components.
Number 7:

17. Non-injurious Injections
•Lorem ipsum dolor
•Consectetur adipiscing elit
•Sed do eiusmod tempor
•Incididunt ut labore
•Lorem ipsum dolor
•Consectetur adipiscing elit
•Sed do eiusmod tempor
•Incididunt ut labore
Properties allow a way to set or retrieve data, provide default values, standardize data and so on. We just saw
how we can instantiate and then set values to mock data as we need to. However, what happens what we are
using a dependency injection system such as Wirebox?
Number 8:

18. How Does DI / Wireboxwork?
Number 8: Non-injurious Injections

19. Handling Handlers
•Lorem ipsum dolor
•Consectetur adipiscing elit
•Sed do eiusmod tempor
•Incididunt ut labore
•Lorem ipsum dolor
•Consectetur adipiscing elit
•Sed do eiusmod tempor
•Incididunt ut labore
Properties allow a way to set or retrieve data, provide default values, standardize data and so on. We just saw
how we can instantiate and then set values to mock data as we need to. However, what happens what we are
using a dependency injection system such as Wirebox?
Number 9:

20. Exasperating Endpoints
•Lorem ipsum dolor
•Consectetur adipiscing elit
•Sed do eiusmod tempor
•Incididunt ut labore
•Lorem ipsum dolor
•Consectetur adipiscing elit
•Sed do eiusmod tempor
•Incididunt ut labore
Properties allow a way to set or retrieve data, provide default values, standardize data and so on. We just saw
how we can instantiate and then set values to mock data as we need to. However, what happens what we are
using a dependency injection system such as Wirebox?
Number 10:

21. Title here....
•Lorem ipsum dolor
•Consectetur adipiscing elit
•Sed do eiusmod tempor
•Incididunt ut labore
•Lorem ipsum dolor
•Consectetur adipiscing elit
•Sed do eiusmod tempor
•Incididunt ut labore
Lorem ipsum dolor sit amet , consecteturadipiscingelit, sed do eiusmod temporincididuntutlabore et dolore
magna aliqua. Ut etiamsit ametnislpurusin mollisnuncsed. Egestaspretiumaeneanpharetra magna. Amet
nullafacilisimorbitempus iaculisurnaid volutpat. Non diam phasellus vestibulum lorem sed risusultricies.
Pellentesquenecnamaliquamsem. Odioutsemnullapharetra diam. Iaculis urnaid volutpatlacus. Tortor
pretiumviverrasuspendissepotentinullamac tortorvitae. Ac utconsequatsemper viverranamlibero justo
laoreet. Facilisimorbitempus iaculisurnaid volutpatlacuslaoreet.

22. Title here....

23. THANK YOU
Thanks to our sponsors