This document discusses the importance of testing software. It outlines 30 tips for writing tests, including writing tests before code, treating tests like code, minimizing asserts per test, using data providers, and allocating time for testing in estimates. Testing helps catch bugs, improve code quality, and ensure stability. The document emphasizes that automated testing is key and should test everything that could break an app.

1. TESTIMONYTESTIMONY
(ABOUT TESTING)(ABOUT TESTING)
Presented by /Milan Popović @komita1981

2. MEME
PHP developer
Work for Navus Consulting GMBH
I like to learn and share knowledge
Active member of PHP Srbija

3. What is main property of bad code?
IT'S UNTESTABLEIT'S UNTESTABLE

4. KENT BECK'S RULES OF SIMPLEKENT BECK'S RULES OF SIMPLE
CODECODE
1. Runs all the tests
2. Contains no duplication
3. Express the intent of programmer
4. Minimizes the number of classes and methods
Given in order of importance

5. No so ware engineers release even the
tiniest change without testing, except
the very confident and the very sloppy.
- Kent Beck

6. The degree to which you know how
your so ware behaves is the degree to
which you have accurately tested it. -
Max Kanat-Alexander

7. WHAT DO PEOPLE THINK ABOUTWHAT DO PEOPLE THINK ABOUT
TESTING?TESTING?

13. Time consuming
Testing is hard
Steep learning curve
Don’t make anybody any money

14. WHAT TESTING REALLY IS?WHAT TESTING REALLY IS?
Fundamental part of professional so ware
development
Prove you've done your work
An insurance that the system works
Reduce number of bugs
Help you make better code design - easier to maintain
- facilitating change

15. WHAT TESTING REALLY IS?WHAT TESTING REALLY IS?
Ensures stable, long lasting application
Improve understanding how clients are going to use
your code
Enhance security
Provide free documentation

16. COST OF NOT TESTING OR LATECOST OF NOT TESTING OR LATE
TESTINGTESTING
Testing is expensive (event up to 40% of project's
budget)
Not testing is event more expensive
Cost of testing increases exponentially if happens later

17. WHY DO SO MANY DEVELOPERSWHY DO SO MANY DEVELOPERS
NOT DELIVER TESTS WITH THEIRNOT DELIVER TESTS WITH THEIR
CODE?CODE?
Habit is not established early
The consequence of not writing unit tests is delayed
The consequence is o en suffered by other people, not
the original author
Informational Conformity

18. WHAT IS TO BE TESTED?WHAT IS TO BE TESTED?
EVERYTHINGEVERYTHING
To be more precise
EVERYTHING THAT COULD BREAKEVERYTHING THAT COULD BREAK
YOUR APPYOUR APP

19. DDT VS TDD VS TFD VS BDD VSDDT VS TDD VS TFD VS BDD VS
WHATEVERWHATEVER

20. IBM & Microso - TDD - 20-40% longer to complete but
40-90% fewer bugs in production

21. By 2022 it will be not be possible to get
a professional programming job if you
do not practice TDD routinely - Allan
Kelly

22. STATE OF MINDSTATE OF MIND

23. LEVELS, TYPES AND METHODSLEVELS, TYPES AND METHODS
OF SOFTWARE TESTINGOF SOFTWARE TESTING

24. LEVELSLEVELS
Unit
Integration
System
Acceptance

25. TYPESTYPES
A/B
Acceptance
Accessibility
Alpha/Beta
Concurrent
Conformance and type

26. TYPESTYPES
Compatibility
Destructive
Development
Documentation
Functional vs Non Functional
Internationalization & Localization

27. TYPESTYPES
Installation
Performance
Regression
Smoke and Sanity
Security
Usability

28. METHODSMETHODS
Static
Dynamic

30. 1. Try with writing tests a er writing the code

31. 2. When you get confidence try to write tests before the
code

32. 3. Treat test like your code - keep it "clean"
Be descriptive about what you are testing
Do not duplicate test code
Do not make tests complex

33. 4. Number of asserts in a test ought to be minimized

34. 5. Use Virtual Environments

35. 6. Use continuous integration server
When I say testing I mean AUTOMATED testing
Automated testing is key point for so ware quality and
is preferred because of it's repeatability and easy of
use
Manual testing is time consuming and boring allowed
in some complex scenarios
Run tests o en

36. 7. Test Boundary Conditions

37. 8. Use test saboteurs
Humbug
Infection

38. 9. Use test coverage properly
A rule of the thumb for test coverage related to
cyclomatic complexity is to have test cases equal in
number to the cyclomatic complexity value.

40. Test branch coverage not only code coverage
sampleMethod()
{
if (a < 5 and b > 10){
return a + b;
}
return $a - $b;
}

41. 10. Test before refactoring

42. 11. Write unit tests for each bug you are going to fix

43. 12. Think twice before using New Operators - new
ClassName()

44. 13. Think twice before using statics -
SomeClass::someMethod()

45. 14. Avoid endless "anding" - Breaking SRP

46. 15. Avoid using switch-case o en - use design patterns
instead

47. 16. Avoid using too many dependencies - max 4
dependencies

48. 17. Avoid logic in constructor - only assign variables

49. 17. Do not break Law of Demeter
$company->getOwner()->getAccount()->getBank()...

50. 18. Do Not Mock What You Do not Own

51. 19. Use data providers
/**
* @dataProvider getSuccessfulAddData
*/
public function testSuccessfulAdd($a, $b, $result)
{
$this->assertEquals($result,
$this->calculator->add($a, $b));
}
public function getSuccessfulAddData()
{
return [
['a' => 1, 'b' => 2, 'result' => 3],
['a' => 2, 'b' => 1, 'result' => 3],
['a' => 0, 'b' => 1, 'result' => 1],

52. 20. Respect 3A of Unit testing
Arrange objects, creating and setting them up as
necessary.
Act on an object
Assert that something is as expected

53. 21.

54. 22. Programming by Wishful Thinking

55. 23. Use test doubles properly
Dummy
Fake
Stub
Mock
Spy

56. 24. Before asserting through loop use assertCount

57. 25. Do not lie about your real dependencies - use DI
Don't look for things! Ask for things!

58. 26. Smoke testing
Quick check if there are any problems
Check if application is running
Ping an important API endpoint

59. 27. Add time for testing in your estimates
30% testing
30% implementation
10% logging and metrics
30% refactoring

60. 28. If you provide API use documentation testing
Dredd
Supports Swagger & API Blueprint

61. 29. Run tests in parallel

62. 30. Weeks of programming can save you hours of
planning and writing tests

64. Once you start testing You wont want to write code
without tests again
You are not good developer if you are not good tester
Developers starts producing better code
Testing makes developers complacent
Writing code that is testable encourages best practices
- such as SOLID
Quality is everyone’s responsibility — especially ours -
developer’s
Testing is fun :-)

75. f u cn rd ths, u cn gt a gd jb n s wr tstng

76. RESOURCESRESOURCES
Php tests tips
Unit test prez
Cost of tdd
Sebastian Bergmann in Atlanta
F.I.R.S.T Principles of Unit Testing
First principles
Prag prog blog
How O en Should You Run Your JUnit Tests?
Daed blog
Salesforce blog
Google testing blog

77. Unit testing blog
Testing doubles
Martin Fowler about XUnit
Notes on designing through mocking
Wishful Programming
That's Not Yours
Testing is dead
So ware Testing
So ware Testing
So ware Testing Concepts

78. IMAGESIMAGES
We are busy
Vagrant & Docker
TDD lifecycle
Testing code in production
Hard work
Steep learning curve
Advice
True or false
Testing pyramid
Inverted Testing pyramid
Hourglass

79. Kohana testing structure
Facts
Unit testing mvc
Make it brake it

80. THANK YOUTHANK YOU

81. QUESTIONS?QUESTIONS?