Slide 1
Slide 1 text
What’s wrong with testing?
What is the secret of happiness in testing?
THE ATOM OF
SOFTWARE TESTING
Unit Testing
Slide 2
Slide 2 text
ÖMER KORKMAZ
software engineer
Farmazon
researcher
Sabanci University
omerkorkmazz omr_korkmaz
alumni
Ciceksepeti, Altinbas, Mercedes-Benz Turk
omeerkorkmazz
Slide 3
Slide 3 text
Take a coffee and write some codes
Deploy your codes and
make your customers happy
Take another coffee and
refactor your codes
WHAT IS ROUTINE ?
Slide 4
Slide 4 text
BUT, SUDDENLY...
Fix bug1, bug2, bug3, .. Hurry up for hot-fix!
Other bugs triggered,
solve them!
Slide 5
Slide 5 text
WHAT’S WRONG
WITH MY CODE ?
Is my code dead ?
Is my code alive ?
Slide 6
Slide 6 text
—Jack W. Reeves
“Coding is design, testing and
debugging are part of design.”
http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
Slide 7
Slide 7 text
is real software design
SOURCE CODE
01
Slide 8
Slide 8 text
Sour code should not be DETESTABLE
TESTABILITY
02
Slide 9
Slide 9 text
SOFTWARE
DESIGN
CODING
TESTING
Slide 10
Slide 10 text
SOFTWARE
DESIGN
CODING
TESTING
REFACTORING
Slide 11
Slide 11 text
DEADLINE!
Code is smelling..
I can’t write tests!
Method is so
complex. I don’t
have time to
write tests!
Nobody pushes
themselves to
write tests!
It works my local.
Also, I completed
manual tests!
Slide 12
Slide 12 text
—Edsger Dijkstra
“Testing shows the presence, not
the absence of bugs.”
Slide 13
Slide 13 text
UNIT
INTEGRATION
ACCEPTANCE
LOAD
SMOKE
FUNCTIONAL
PERFORMANCE
MANUAL
STATIC
SYSTEM
REGRESSION
A / B
TEST METHODOLOGIES
...
Slide 14
Slide 14 text
UNIT
INTEGRATION
ACCEPTANCE
LOAD
SMOKE
FUNCTIONAL
PERFORMANCE
MANUAL
STATIC
SYSTEM
REGRESSION
A / B
THE ATOM !
...
Slide 15
Slide 15 text
WHAT IS UNIT TEST ?
01
Code typically written by
developers to ensure that code
meets requirements.
02
03 Isolate each part of the program
and show individual parts behave
as expected.
Smallest unit of functionality and
focuses on one particular feature
Slide 16
Slide 16 text
IN TRADITIONAL TESTING..
● Test the system as a whole.
● Individual components rarely
tested
● Errors are undetected
● Isolations of errors difficult to
track
Slide 17
Slide 17 text
IN UNIT TESTING..
● Each part tested individually
● All components tested at least
once
● Easy to detect errors
● Smaller scope, fix defects
easier
Slide 18
Slide 18 text
01
FUNCTIONAL CORRECTNESS
01
It provides developers to make sure that whether the
implemented functionality behaves as expected!
Slide 19
Slide 19 text
01
CORRECTNESS OF OUTPUT DATA
02
Outputs of the methods should be obtained as usual.
Slide 20
Slide 20 text
01
ERROR HANDLING
03
It is easy to detect the errors in complex units when testing
each functionality as a small unit!
Slide 21
Slide 21 text
UNIT TEST DO NOT..
ACCESS THE NETWORK
CONNECT TO DATABASE
CREATE NEW THREADS
ACCESS THE FILE SYSTEM
Slide 22
Slide 22 text
—Dave Cheney
Project Member
of
Go Programming Language
Slide 23
Slide 23 text
BUT, UNIT TEST DO ?
ACCESS THE NETWORK
CONNECT TO DATABASE
CREATE NEW THREADS
ACCESS THE FILE SYSTEM
MOCKS
STUBS
Slide 24
Slide 24 text
—Martin Fowler
“Mocks aren't stubs.”
https://martinfowler.com/articles/mocksArentStubs.html
Slide 25
Slide 25 text
—Martin Fowler
“Mocks are objects pre-programmed with
expectations which form a specification of the
calls they are expected to receive.”
https://martinfowler.com/articles/mocksArentStubs.html
Slide 26
Slide 26 text
—Martin Fowler
“Stubs provide canned answers to calls made
during the test, usually not responding at all to
anything outside what's programmed in for
the test.”
https://martinfowler.com/articles/mocksArentStubs.html
Slide 27
Slide 27 text
FASTER DEBUGGING AND DEVELOPMENT
BETTER DESIGN
REDUCE FUTURE COST
WHY UNIT TESTS ?
Slide 28
Slide 28 text
UNIT TEST LIFE CYCLE
Re-execute
unit tests
Fix defects
Execute
unit tests
Make changes
Code
review
Apply
changes
Slide 29
Slide 29 text
GUIDELINES
Slide 30
Slide 30 text
Multiple runs of the test should consistently
return true or consistently return false.
CONSISTENCY
01
var time = DateTime.Now;
string id = Guid.NewGuid();
??
Slide 31
Slide 31 text
Tests should be PASS or FAIL
No partial successful tests!
ATOMIC
02
Test A should not depend on
the outcome of Test B
!
Slide 32
Slide 32 text
One test should be responsible for one use-case!
SINGLE
RESPONSIBILITY
03
One method
multiple conditions
MULTIPLE TESTS
!
One behavior
multiple methods
ONE TEST
!
Slide 33
Slide 33 text
Unit tests must be easy to
● understand
● read
UNDERSTANDABILITY
04
Should_Foo_Return_Null_When_Throws_
Exception()
!
Self-descriptive method and
variable names
!
Slide 34
Slide 34 text
Unit tests should not have
conditional logics or loops!
NO CONDITIONS
05
Do not use While or If statements
!
Split into multiple tests
rather than using “if”
!
Slide 35
Slide 35 text
Catch only the expected type of exception
NO EXCEPTION
HANDLING
06
Fail test → undetectable exceptions
!
Slide 36
Slide 36 text
Assertion messages should be clear
when reading to see why test failed
and what to do
ASSERTIONS
07
“GetProductAsync should return null
when throwing SQL exception”
!
“CreateOrder should return true
when created successfully”
!
Slide 37
Slide 37 text
Do not create methods or properties
used by only the tests!
NO TEST LOGIC
08
Separate unit tests and product
codes in different projects
!
Slide 38
Slide 38 text
Create different test projects for
every layer or assembly
MODULE SEPARATION
09
FarmaLab.Tests.Domain
FarmaLab.Tests.Manager
!
Slide 39
Slide 39 text
While testing the methods, make sure
boundary cases are tested!
BOUNDARIES
10
BOUNDARY TESTING
ROBUST BOUNDARY TESTING
!
if(3<= age < 20)
{
//how to test the age?
}
!
Slide 40
Slide 40 text
When bug is reported, write some
tests to reproduce the bugs and use
the test as success criteria to fix it
REPRODUCING BUGS
11
Sounds like TDD?
● Write the fail test
● Change it to pass
?
Slide 41
Slide 41 text
—Misko Hevery
“The secret of testing is writing
testable code.”
https://twitter.com/mhevery
Slide 42
Slide 42 text
THANK YOU !
Questions & Answers