Continuous
Confident Testing
The art of confident Software Development in an agile environment
LOADING AWESOME
15+ Years in Software Development
Experience in Stand Alone Applications, SaaS Applications, Small and Large Businesses.
INTRODUCTION
https://www.continuousconfidence.com
Michael Bright
Senior Software Engineer, DevOps, Continuous Integration Expert, with an IT Degree
Software Releases
Why are they so...complex?
SaaS
LOADING AWESOME
How did I get here?
- Yearly Release Cycle
- Millions of lines of code
- Multiple years behind schedule
- Monthly patch release
Company 1
- Long QA Cycle
- Complex QA, Different Dept.
Company 2
- SaaS Product
- 6-8 Week Release Cycle
- Around 100,000 Lines per release
- 1 week Regression Suite
(60 QA x 40 hours)
- Feature cycle more than 1 year out
- Go/No Go Meetings
- Stability Concerns - LARGE tech debt
Company 3
- SaaS Product
- Release up to 18 times a day
- No regression suite
- Negative Bug trend
- Automated Release / Rollback
- No deadlines
- No Seleniums
- 2 week ahead Product Backlog
LOADING AWESOME
Confident Testing
4-THINGS TO CONSIDER
4 Things to Test
What are we deciding to do?
Logic
What does our code assume?
Assumptions
What are the contracts of our code?
Contracts
Changes
What did we change?
WHAT IS LOGIC?
Parts of the code where we assign variables or flow of the code.
1. Assignments
Standard statements such as If/Else, Switch, or Ternary code statements.
2. If/Else Statements
What exceptions are thrown?
When do they get thrown?
How are they dealt with?
3. Exceptions
What methods are we calling?
4. Code Flow
var foo = 'Bar';
var trial = {'key' => 'value'}; var CONSTANT = 'NEW';
if(true) { } else {}
if(true && false) {}
if(true || false) {}
true ? A : B
something.method()
{ return other.trial()}
WHAT DO WE ASSUME?
Do we have empty arrays, or maps that we assume will be filled?
1. Are things Empty?
Nulls are not our friends. Could we potentially reference a null?
2. Is something null?
Do we assume the structure that is being passed in, or used?
3. The structure?
Do we assume that we will always get the right contract? What about exceptions?
4. Contract honored?
var arr = [];
arr[1].callSomething();
function(v) {
return v.something()
}
public static int callMe(Object obj){ return obj.takeOverTheWorld();
}
WHAT ARE CONTRACTS?
What comes into our classes, methods, how do we interact with our code?
1. Inputs/Outputs
When you make a call to a different method external to the class, you are defining what it will do.
2. Code Flow
When you throw or swallow an exception, that is a contract to the external caller.
3. Exceptions
Public, private, package - We determine the scope and thus how something will be used. Contracts determine this.
4. Scope
WHAT DID WE CHANGE?
Don't go back and test something we didn't change. Assume it will work the way it did prior to our change.
1. Assume the Best!
If it is NOT unit testable, we probably didn't do it right.
2. Make it Testable
Write unit tests, and not integration tests. They will help us know what changed.
3. Unit not Integration
Things to go by
Tidbits of knowledge to help with implementing Confident Testing
Tests verify code, they do not enforce code. Architecture enforces code and structure.
"
If you don't feel confident, ask yourself: What will make me more Confident?
"
CONFIDENCE PROMOTER SCORE (CPS)
If we are here, we are generally missing Specifications and direction.
1-5
This indicates a lack of knowledge somewhere. Questions still needing to be answered.
6&7
Things are pretty well understood and are probably ready for QA and production.
8-10
On a scale from 1-10 how confident am I in my code?
LOADING AWESOME
THANK YOU
Sed dignissim elementum quam, vel maximus libero pharetra quis.
Morbi ornare purus a metus maximus accumsan.
Continuous Confidence
