Effective Programmer's Tests with Java.pdf

Write effective tests

1. Rafael Gutiérrez, Software Engineer @ Encora
Encora Hacker House, May 2022
Effective Programmer's Tests with Java

2. •Should a Programmer tests?
•Types of Sofware Testing
•Value of having tests
•Java Testing Tools
•Concepts and Patterns
•Test Readability
•Test Maintainability
•Test Trustworthiness
•EOF
Agenda

4. Should a Programmer test?
•Testing is not only responsibility of QA
•Testing is not something that somebody else does
•We (programmers) must take responsibility
•We (programmers) must write tests for our code to make sure code is
working properly
•We (programmers) must write automated tests

5. Types of Software Testing
•Unit Tests
•Integration Tests
•End-to-End Tests
•Acceptance Tests
•Performance Tests
•Smoke Tests

6. Value of having tests
•Tests helps us catch mistakes
•Tests helps us shape the design
•When applying Test Driven Development (TDD)
•When refactoring
•Tests helps us avoid gold-platingby being explicit about the actual
behavior

7. Java Testing Tools (some)
•Unit Testing -> JUnit,TestNG,EasyMock, Mockito,Spock
•Integration Tests -> DBUnit
•End-to-End Testing ->Selenium WebDriver, Selenide, Geb, Cucumber
•Performance Test -> Apache JMeter
•Supporting Tools -> AssertJ, Hamcrest, Liquidbase, Flyway,
Testcontainers

8. Concepts and Patterns

9. Assertions
How do you know your tests worked correctly?
Write code that automate your judgmentabout
whether the code worked

10. Test Doubles
Generic term for any case where you replace a production object for
testing purposes.

11. Test Doubles
•Dummy –passed around, not really used. To fill parameter list
•Fake –working implementations but taking shortcuts. For example,
InMemoryTestDatabase
•Stubs –provide canned answers for the test, no responding to
everything outside the test
•Spies –Stubs to record information to be verified later (in asserts)
•Mocks –pre-programmed with expectations. They can throw
exceptions if a call was not expected, or the number of expected calls
is different

12. AAA Pattern
The AAA Pattern (3A Pattern) suggest to split each tests into three parts:
•Arrange
•Act
•Assert

13. Test Fixture
Code that is run to configure the system under test
Test data that needs to be set up as a precondition before a test is run—
often this means populating the database with some information,
creating the objects the tests is going to use, etc.

14. Test Readability

15. Primitive assertions
•Assertions should express an assumption or intent
•Primitiveassertions hidden the intent behind some meaningless
words or numbers
•Cognitive load for other developers

16. Primitive assertions -:( example

17. Primitive assertions -:D example

18. Primitive assertions –example 2
Or the famous case of "what the heck is this supposed to do?"

19. Hyperassertions
•Too scrupulous that become brittle and hides intent
•Overwhelming! Checking too many things
•Fragile, breaking frequently (flaky)
•Single Responsibility violation
A test should have only one reason to fail

20. Hyperassertions-example

21. Incidental Details
•Code is readable when it's intent, purpose, and meaning is clear
•Scan the code and say "Ah! This thing is doing …"
•Incidental =accompanying but not a major part of something

22. Incidental Details -:( example

23. Incidental Details -:D example

24. Split personality
•Atest should only check one thing and check it well
•If tests doing too many checks –split the test

25. Split personality -:( example

26. Split personality -:D example

27. Split logic
•Nobody likes long methods
•Use "chunking" to improve readability
•cognitive psychology
•Do not blindly extract smaller methods,
but rather do it mindfully

28. Split logic -:( example

29. Split logic -:D example

30. Magic Numbers
•Magic numbers are bad and should be avoided
•Magic numbers appear in assignments, method calls, and other
program statements
•They don’t reveal their meaning

31. Magic Numbers -:( example

32. Magic Numbers -:D example 1

33. Magic Numbers -:D example 2

34. Setup sermon
•Sometimes we have lot of code just to prepare everything for the
test (setup method)
•The same treatment that we apply to production code should be
applied to test code (at all levels –test methods, setup methods,
etc.)

35. Setup sermon -
:( example

36. Setup sermon -:D example

37. Overprotective tests
•NullPointerException(our old friend) have made Devs to be
overprotective in their code
•Bepragmatic, remove redundant asserts

38. Overprotective tests -:( example

39. Overprotective tests -:D example

40. Test Maintainability

41. Duplication
•Duplication
•Duplication
•Duplication
•(DRY) Don't repeat yourself!

42. Duplication -:( example

43. Duplication -:D example

44. Conditional Logic
•Loops and conditional statements can be essential tools in test
helpers
•Avoid conditional logic in test methods, they can be
verydistracting

45. Conditional Logic -:( example

46. Conditional Logic -:D example

47. Flaky Tests
•Tests are like our friends
•If some issue was introduced, we should trust our tests to alert us
about that
•Testing when non-deterministic behavior (time, random, etc.) is
involved can be tricky

48. Flaky Tests -:( example

49. Flaky Tests -:D example

50. Crippling file path
•"It runs in my machine!"
•Prevents your tests from running in anyone else machine
•Avoid hardcoded values

51. Crippling file path -:( example

52. Crippling file path -:D example

53. Persistent temp files
•Temporary file should be temporary
•Delete resources your tests create

54. Persistent temp files -:( example

55. Persistent temp files -:D example

56. Sleeping snail
•We should be able to get feedback quickly from our tests
•UsingI/O (Files) in our tests can make them slow
•Using Thread.sleep() will make them slower!
•Just as testing non-deterministic behavior can be tricky, same when
testing Threads

57. Sleeping snail -:( example

58. Sleeping snail -:D example

59. Parameterized mess
•You find yourself with duplicated methods where the test data and
the expected results is the only thing that vary?
•Remove duplication, use parameterized tests
•But use parameterized tests with care

60. Parameterized mess -:( example

61. Parameterized mess -:D example

62. Lack of cohesion in methods
•Simply put, cohesion means that a class represents a single thing, a
single abstraction
•Perfect cohesion means that every field of a class is used in every
method
•In tests classes, this means that every test method is using the
same test fixture

63. Lack of cohesion in methods -:( example

64. Lack of cohesion in methods -:D example

65. Test Trustworthiness

66. Commented-out tests

67. Misleading comments
•Comments that suggest something that is not true
•Comments are not executable (like code), they can go stale

68. Misleading comments -:( example

69. Misleading comments -:( example

70. Never-failing tests
•Never-failing tests are like Chuck Norris, they never fail!
•False sense of security

71. Never-failing tests -:( example

72. Never-failing tests -:D example

73. Emptypromises

74. Lowered expectations
•Lazy testing
•Vague assertions

75. Conditional tests
•Hiding secret conditionals
•Using conditionals for "assumptions" or preconditions for our tests

76. Conditional tests -:( example

77. Conditional tests -:D example

78. •Avoid complex private methods
•Avoid final methods
•Avoid static methods
•Use `new` with care
•Avoid logic in constructors
•Avoid singleton
•Favor composite over inheritance
•Wrap external libraries
•Avoid service lookups
•Favor dependency injection
Simple guidelines for
testable design

80. Want to learn more?
•Test Infected: Programmers love writing tests, Kent Beck and
ErichGamma (Article)
•Effective Unit Testing, Lasse Koskela, 2013 (Book)
•Growing Object-Oriented Software Guided by Tests,Steve Freeman
and Nat Pryce(Book)
•Test-Driven Development by Example, Kent Beck (Book)
•Unit Testing Principles, Practices and Patterns,Vladimir
Khorikov2020 (Book)

81. JVM MX
•Comunidadde Java Mexico
•Redes sociales:
•https://youtube.com/c/javamexico
•https://facebook.com/javamexico
•https://twitter.com/jvm_mx
•https://twitter.com/javamexico
•https://github.com/javamexico

82. Questions time!

83. Thank you!