2. About me
● Software engineer since ~2000 - mainly Oracle database
● Infected with testing and automation since ~2013
● Key contributor, author and maintainer of utPLSQL v3
● Active developer, learner, testing advocate
5. ● Check that software “works”
Why do we test?
● Find bugs
● Prove that solution meets requirements and expectations
● Prove that change didn’t break existing functionality
● Document requirements and reveal intention
6. Automatic test generators
● Find bugs
● Check that software “works”
● Prove that solution meets requirements and
expectations
● Prove that change didn’t break existing
functionality
● Document requirements and reveal intention
● Created from the code
● Created for the code
● Confirm that code “does stuff”
● No confidence that code
“does the right thing”
● No reference to requirements
7. ● Behavior
○ Logic
○ in / out structures
○ State (?)
● Avoid
○ under / over testing
○ unstable tests
○ slow tests
○ testing code you don’t own
What to
test?
8. ● Test early (TDD)
● Test often
● Test automatically (CI/CD)
When to
test?
https://www.google.com/search?q=test+early...
9. Properties of Unit Tests
● Fast
● Isolated
● Repeatable
● Self-verifying (obvious)
● Thorough & Timely
https://github.com/ghsukumar/.../F.I.R.S.T-Principles-of...
https://pragprog.com/magazines/2012-01/unit-tests-are-first
How to
test?
10. Test Driven Development
● write a test
● see it fail
● keep it simple
● tests are examples
● tests become
documentation
● get to green fast
● take baby steps
● stuck?
undo and start over
● write only enough
code to pass the test
● remove duplication
(in code and tests)
● rename and clean up
● run tests and stay green
● change implementation,
not behavior
● improve structure
in small steps
RED GREEN
REFACTOR
With TDD you get:
● Fast feedback loop
● Visible & iterative progress
● Code is tested before it exists
● Feeling of accomplishment
with every new test
12. function - Create room
● Creates a room with given name and returns it’s id
● Throws exception when room name is null
● Throws exception when room exists
13. Remove room by name
● Removes room that has no content
● Throws exception when room is not empty,
keeps the room and it’s content
● Throws exception when room does not exist
● Throws exception when null room name given
14. Add room content
● Fails when room does not exist
● Fails when content name is null
● Adds content to existing room
15. ● free & open source
● self tested & compatible with Oracle 11gR2+
● IDE independent
● pure PL/SQL
● tests described only by annotations & expectations
● implements best testing patterns
● easy to Version Control
● transportable
● automatic transaction - no rollback/cleanup needed
● data type - aware comparison (expectations)
Why utPLSQL v3 ?