|
| 1 | +# Unit Testing Cheat Sheet for Codebase |
| 2 | + |
| 3 | +## Testing Libraries and Frameworks |
| 4 | +- Jest (assumed, as PowerMock is mentioned which is often used with Jest) |
| 5 | +- PowerMock (for invasive mocking, discouraged in the article) |
| 6 | + |
| 7 | +## Mocking and Stubbing |
| 8 | +1. Avoid using PowerMock for invasive mocking |
| 9 | +2. Prefer dependency injection through constructors for easier mocking |
| 10 | +3. Use Ports & Adapters pattern to isolate dependencies |
| 11 | +4. Mock dependencies, not statements |
| 12 | +5. Avoid `when-then` statements in tests |
| 13 | + |
| 14 | +Example of bad mocking (to avoid): |
| 15 | +```java |
| 16 | +Whitebox.setInternalState(...); |
| 17 | +when(...).then(...); |
| 18 | +doNothing().when(...); |
| 19 | +``` |
| 20 | + |
| 21 | +## Fake Implementations |
| 22 | +- Use fake adapters for testing instead of real implementations |
| 23 | +- Implement interfaces (ports) with test-specific adapters |
| 24 | + |
| 25 | +## Testing Strategies |
| 26 | +1. Black-box Unit Testing |
| 27 | + - Test component behavior without knowing internals |
| 28 | + - Focus on inputs and outputs, not implementation details |
| 29 | + |
| 30 | +2. Behavior-driven Testing |
| 31 | + - Emphasize behavior coverage over statement coverage |
| 32 | + |
| 33 | +3. Ports & Adapters Architecture |
| 34 | + - Use interfaces (ports) to define dependencies |
| 35 | + - Implement adapters for production and test environments |
| 36 | + |
| 37 | +Example: |
| 38 | +```java |
| 39 | +public interface PokemonRepository { |
| 40 | + List<Pokemon> findAll(); |
| 41 | +} |
| 42 | + |
| 43 | +public class FakePokemonRepository implements PokemonRepository { |
| 44 | + @Override |
| 45 | + public List<Pokemon> findAll() { |
| 46 | + // Return test data |
| 47 | + } |
| 48 | +} |
| 49 | +``` |
| 50 | + |
| 51 | +## Best Practices |
| 52 | +1. Avoid void methods in tested components |
| 53 | +2. Avoid static methods that mutate state or have side effects |
| 54 | +3. Always inject dependencies through the constructor |
| 55 | +4. Design components with testability in mind |
| 56 | +5. Use Ports & Adapters to interact with legacy code indirectly |
| 57 | +6. Focus on behavior documentation in tests |
| 58 | +7. Treat unit tests as the first client of your component |
| 59 | + |
| 60 | +## Anti-patterns to Avoid |
| 61 | +1. Using PowerMock or similar invasive tools |
| 62 | +2. Tightly coupling tests to implementation details |
| 63 | +3. Breaking encapsulation in tests |
| 64 | +4. Mocking internal state or private methods |
| 65 | +5. Focusing on statement coverage instead of behavior coverage |
| 66 | + |
| 67 | +## Testing Legacy Code |
| 68 | +1. Introduce a level of indirection using Ports & Adapters |
| 69 | +2. Create interfaces for legacy dependencies |
| 70 | +3. Implement fake adapters for testing |
| 71 | +4. Inject fake adapters during tests |
| 72 | + |
| 73 | +## Code Structure for Testability |
| 74 | +1. Separate domain logic from side effects |
| 75 | +2. Use dependency injection |
| 76 | +3. Create interfaces for external dependencies |
| 77 | +4. Implement adapters for different environments (prod, test) |
| 78 | + |
| 79 | +Example of a testable component structure: |
| 80 | +```java |
| 81 | +public class PokemonCollector { |
| 82 | + private final PokemonRepository repository; |
| 83 | + private final PokemonValidator validator; |
| 84 | + |
| 85 | + public PokemonCollector(PokemonRepository repository, PokemonValidator validator) { |
| 86 | + this.repository = repository; |
| 87 | + this.validator = validator; |
| 88 | + } |
| 89 | + |
| 90 | + public List<Pokemon> collectValidPokemon() { |
| 91 | + return repository.findAll().stream() |
| 92 | + .filter(validator::isValid) |
| 93 | + .collect(Collectors.toList()); |
| 94 | + } |
| 95 | +} |
| 96 | +``` |
0 commit comments