Unit Testing and TDD

Question 1

Unit Testing

Answer 1

Testing units in a system, in OOP this means individual classes and methods. Should account for most of the testing in a project and done by developers.

Question 2

JUNIT

Answer 2

testing framework for java using Maven.

Question 3

Anatomy of a Unit Test

Answer 3

Setup
Exercise
Verify
Teardown

Question 4

Before and After Methods

Answer 4

• Setup and Teardown actions can be repetitive across tests.
• JUNIT provides easy ways of defining these
• Methods tagged with @BeforeEach will run before each test
• Same way with @AfterEach
• BeforeAll and AfterAll are the same

Question 5

What makes a good unit test

Answer 5

• Descriptive name
• Tests one thing
• Always returns the same result
• Has no conditional logic
• Independent of other tests
• So understandable that it acts as documentation

Question 6

What makes a bad unit test

Answer 6

• Interacts with external databases
• Communicates across a network
• Interacts with a file system
• Must be executed after specific tests
• Requires configuration of the environment

Question 7

Code Coverage

Answer 7

Measure used to describe how much of the source code has been executed when the test suite runs. The goal is at least 80%.

Question 8

Does 100% code coverage mean no bugs?

Answer 8

No, there might be unreachable code

Question 9

Test Driven Development

Answer 9

Write enough code to pass the test

Question 10

Benefits of TDD

Answer 10

• Driven by clear goals
• Safer Code
• Isolation of incorrect code
• Easily introduce new functionality
• Document the application as you go

Question 11

Testing Doubles

Answer 11

Dealing with indirect inputs and outputs, an object in place of a real component for the purpose of running a test, includes; dummies, spies, stubs and mocks.

Question 12

Dummy Objects

Answer 12

Degenerate form of test double, not used by the DOC or used in a limited manner. Usually an alternative to using null objects. Only exist to be passed around

Question 13

Test Stubs

Answer 13

Replace a real component on which SUT depends. Delivers a pre-canned response and produces indirect input to force the execution of specific code paths.

Question 14

Test Spies

Answer 14

More advanced form of stub, besides producing indirect inputs, spies can monitor and record indirect outputs. Test driver can verify with a spy that something has been produced.

Question 15

Mock Objects

Answer 15

Powerful, do everything a stub or spy does but also verifies SUT behavior. Test driver tells the mock what sort of behavior is expected during the test, and the mock will verify that the behavior was observed. Using mocks requires proper layering of your system.

Question 16

Setting up a Mock with Mockito

Answer 16

1. Define TimeProvider Interface
2. Write your SUT code
3. Write your tests using mocks

You don’t need to create an interface for every item you want to mock, especially if the class you want to mock is not implemented.

Question 17

Test Patterns

Answer 17

A design pattern is similar to a recipe where a solution to a common design problem is explained. Test patterns are the same way but in testing. Directly influence the system design.

Question 18

Dependency Injection

Answer 18

Avoid hardcoding dependencies into the system, find a way to allow depended upon components to be set at runtime (Parameter, Constructor, Setter Injection)

Question 19

Dependency Lookup

Answer 19

Design system in order to look up dependencies at runtime when their need arises. Usually a factory approach is taken. Tests can gain control of the factory to then control dependencies for testing purposes.