Testing

When using the @SpringBootApplication, all components normally a part of the application will be part of the test. Be sure to define auto-configuration exclusions for any production components that would need to be turned off during testing.

@Configuration
@ConditionalOnProperty(prefix="hello", name="enable", matchIfMissing="true")
public Hello quietHello() {
...
@SpringBootTest(properties = { "hello.enable=false" }) (1)

1	test setting property to trigger disable of certain component(s)

1	test case class is instantiated per method
2	any shared state must be declared private
3	`@BeforeAll` and `@AfterAll` methods must be declared static
4	`@Test` methods are normal instance methods with access to the static state

1	JUnit Vintage syntax places optional message as first parameter
2	JUnit Jupiter moves the optional message to the last parameter
3	JUnit Jupiter also allows optional message to be expressed thru a lambda function
4	Hamcrest passes message in first position like JUnit Vintage syntax
5	AspectJ uses an `as()` builder method to supply a message
6	AspectJ also supports `String.format` and args when expressing message

1	JUnit `DisplayNameGenorator.ReplaceUnderscores` will form a natural-language display name by replacing underscores with spaces
2	JUnit `DisplayName` sets the display name to a specific value
3	JUnit `Nested` classes can be used to better express test context
4	Mockito `when/then` syntax replaced by `given/will` syntax expresses the definition of the mock
5	Mockito `verify/then` syntax replaced by `then/should` syntax expresses assertions made on the mock
6	AssertJ `then` syntax expresses assertions made to supported object types
7	AssertJ `and` field provides a natural-language way to access both AssertJ `then` and Mockito `then` in the same class/method

1	instruct the Mockito mock to return a tip result
2	call method on subject under test
3	verify mock was invoked N times with the value of the bill and service
4	verify with AssertJ that the resulting share value was the expected share value

1	@BeforeClass and @AfterClass called once per test class
2	@Before and @After executed for each @Test

1	@BeforeAll and @AfterAll called once per test class
2	@Before and @After executed for each @Test
3	The default IDE logger formatting added the new lines in between tests

1	one instance is created for all tests
2	any shared state must be declared private
3	`@BeforeAll` and `@AfterAll` methods must be declared non-static

1	JUnit assertions are expressed using a static method and one or more subject arguments
2	Hamcrest asserts that the subject matches a `Matcher` that can be infinitely extended
3	AssertJ’s extensible subject assertion provides type-specific assertion builders

1	a special `SoftAssertions` builder is used to construct assertions
2	we are able to inspect the status of the assertions before failure thrown
3	assertion failure thrown during later `assertAll()` call

1	AssertJ provides means to assert an Exception thrown and provide it for inspection
2	AssertJ provides assertions to directly inspect Exceptions

1	when()/then() define custom conditions and responses for mock within scope of test
2	getValue()/getAllValues() can be called on the captor to obtain value(s) passed to the mock
3	verify() can be called to verify what was called of the mock

1	DisplayName is part of BDD naming and optional for all tests
2	there will be one or more objects under test. These will be POJOs.
3	`@BeforeEach` plays the role of a the container — wiring up objects under test

1	using JUnit snake_case natural language expression for test name
2	BDD convention of given, when, then blocks. Helps to be short and focused
3	using AssertJ assertions with BDD syntax

1	Add Mockito extension to JUnit
2	Identify which interfaces to Mock
3	In this example, we are manually wiring up the subject under test

1	configuring response behavior of Mock
2	optionally inspecting subject calls made

1	defining a custom context that excludes `TipCalculator` component(s)
2	injecting `BillCalculator` bean under test from Spring context
3	defining a mock to be injected into `BillCalculatorImpl` in Spring context

1	execute tests with tag "tips" and without tag "springboot"
2	activating "bdd" profile that configures Surefire reports within the example Maven environment setup to understand display names

1	`@TestConfiguration` annotation prevents class from being picked up in normal component scan
2	`standardTippingImpl` name matches existing component
3	test-specific custom response

1	injected `billCaculator` will be injected with `@Bean` from @TestConfiguration
2	embedded static class used automatically

1	way1 leverages the `@SpringBootTest configuration
2	way2 pre-dates `@SpringBootTest`
3	way3 pre-dates `@SpringBootTest` and is a standard way to import a configuration definition from one class to another