1. Unit testing (look at 1.00)

1.1 Structure

1.2 Assertions

• assertEquals : Assert that the values are equal.
• assertNotEquals : Assert that the values are not equal.
• assertNull : Assert that the value is null.
• assertNotNull : Assert that the value is not null.
• assertSame : Assert that items refer to same object. in terms of Object reference
• assertNotSame : Assert that items do not refer to same object. in terms of Object reference
• assertTrue : Assert that condition is true.
• assertFalse : Assert that condition is false.
• assertArrayEquals : Assert that both object arrays are deeply equal.
• assertIterableEquals : Assert that both object iterables are deeply equal. An "iterable" is an instance of a class that implements the java.lang.Iterable interface Examples: ArrayList, LinkedList, HashSet, TreeSet
• assertLinesMatch : Assert that both lists of strings match.
• assertThrows Assert that an executable throws an exception of expected type.
• assertTimeoutPreemptively Assert that an executable completes before given timeout is exceeded

1.3 Lifecycle

• @BeforeEach : Method is executed before each test method. Useful for common setup code: creating objects, setting up test data.
• @AfterEach : Method is executed after each test method. Useful for common clean up code: releasing resources, cleanning up test data.
• @BeforeAll : Method is executred only once, before all test methods. Useful for getting database connections, connecting to servers. by default this method must be static
• @AfterAll : Method is executed only once, after all test methods. Useful for releasing database connections, disconnecting from servers. by default this method must be static

1.4 Custom Display Names

1.5 Order of the tests

• In general

  • Order should not be a factor in unit tests
  • There should be no dependency between tests
  • All tests should pass regardless of the order in which they are run

• However, there are some uses cases when you want to control the order

  • You want tests to appear in alphabetical order for reporting purposes
  • Sharing reports with project management, QA team etc...
  • Group tests based on functionality or requirements

1.6 code coverage and test reports by intelliJ or Maven

• Code Coverage measures how many methodes/lines are called by your test. Represented as a percentage: 50% coverage
  • In general, the higher the coverage the better
    • However, 100% is not alwats attainble. usually 70% - 80% is acceptable.
  • code coverage is just one data to consider is it a good or bad test. There are a lot of data to consider is it a good or bad test.

1.7 Conditional Tests

• Use Cases

  • Don't run a test because the method to test is broken ... and we are waiting on dev team to fix it
  • A test should only run for a specific version of Java (Java 18) or range of versions (13 - 18)
  • A test should only run on a given operating system: MS Windows, Mac, Linux
  • A test should only run if specific environment variables or system properties are set

• @Disabled : Disable a test method.

• @EnabledOnOs : Enable test when running on a given operating system.

• @EnabledOnJre : Enable test for a given Java version.

• @EnabledForJreRange : Enable test for a given Java version range.

• @EnabledIfSystemProperty : Enable test based on system property.

• @EnabledIfEnvironmentVariable : Enable test based on environment variable.

2. TDD and ParameterizedTest (look at 1.10)

TDD:

1. Write a failing test
2. Write code to make the test pass
3. Refactor the code
4. Repeat the process

Using @ParameterizedTest

• @ValueSource Array of values: Strings, ints, doubles, floats etc
• @CsvSource Array of CSV String values
• @CsvFileSource CSV values read from a file
• @EnumSource Enum constant values
• @MethodSource Custom method for providing values

3 Spring Boot support for Unit Testing (look at 2.00)

3.1 What do we need for Spring Boot unit testing

• Access to the Spring Application Context
• Support for Spring dependency injection
• Retrieve data from Spring application.properties
• Mock object support for web, data, REST APIs etc

3.2 Configuration

4 Mocking (look at 2.20)

4.1 benefits

• Allows us to test a given class in isolation
• Test interaction between given class and its dependencies
• Minimizes configuration / availability of dependencies
• For example DAO, DB, REST API etc
  • We can mock the DAO to give a response
  • We can mock a REST API to give a response

4.2 Mocking Framework

• Mockito. Reccomend because Spring boot has built-in support for Mockito.
• EasyMock
• JMockit

4.3 Process

4.4 @MockitoBean

5 Testing using Reflection

• It is for special cases when you need to access non-public fields or invoke non-public methods

• In general, testing non-public fields and methods is controversial(ขัดเเย้ง). So be careful about it.

6 Database Integration Testing

6.1 Approach

• When we are performing integration testing with a database

  • Each test should run from a known state

• Before each test, perform initialization

  • Insert sample data

• After each test, perform cleanup

  • Delete the sample data

6.2 Set Up SQL Scripts in properties file instead of hardcoding