Angular Unit Testing | TOP 5 Mistakes to Avoid

Summary

In this video, Dmytro Mezhenskyi covers the most common mistakes in Angular unit testing, offering practical solutions. He highlights errors like assigning values in the describe() block, improperly changing component input values, using fragile query selectors, and relying on class-only tests. Dmytro explains how to avoid these issues by using hooks like beforeEach(), proper input updates with setInput(), and using more reliable query selectors. The video also emphasizes testing based on user interactions and ensuring tests remain stable despite component refactors. Additionally, he introduces Wallaby.js for efficient test monitoring, helping developers improve test reliability and maintainability.

Takeaways

• 😀 Avoid assigning values in the describe() function in unit tests, as it can lead to unpredictable test failures when test order changes.
• 😀 Use the beforeEach() hook to initialize variables to ensure consistent values across all tests, reducing side effects between tests.
• 😀 Properly update component input values by using the setInput() method (Angular 14.1+) instead of directly modifying the component class properties to ensure accurate change detection.
• 😀 If using an Angular version older than 14.1, consider using the Test Host strategy to safely update component inputs by modifying the host component's properties.
• 😀 Use explicit selectors for DOM elements in tests, such as data-testId attributes, to avoid breaking tests during component refactoring.
• 😀 Avoid class-only tests where methods and lifecycle hooks are manually called in tests, as it doesn’t simulate real user interactions.
• 😀 Simulate user actions (like changing a select element value) in tests instead of directly invoking component methods to ensure correct behavior under real conditions.
• 😀 When testing component outputs, avoid subscribing to properties directly and instead use a separate variable to track emitted values to avoid false positives.
• 😀 Make sure tests fail when expected outputs aren't emitted by using variables to store the emitted value and asserting it at the end of the test.
• 😀 Consider using Wallaby.js for better real-time test feedback, debugging, and console output directly within your IDE, though it requires a paid subscription for full features.

Q & A

What is the first mistake developers commonly make in Angular unit tests?

The first mistake is assigning values within the `describe()` function. This can cause shared state between tests, leading to unpredictable results because test runners execute tests in random order, which can lead to failures if one test mutates the state used by another test.

How can you avoid the issue of assigning values in the `describe()` block?

To avoid this issue, you should move the assignment operations into the `beforeEach()` hook. This ensures that the value is reset to its default state before each test, making tests independent and stable.

Why is directly changing a component's input value considered a mistake in Angular unit tests?

Directly changing the input values by modifying the component's properties bypasses Angular's normal input binding process. This causes tests to behave differently from the actual application, leading to unstable tests, especially if features like OnPush change detection or Signal inputs are used.

What is the correct way to update component input values in Angular unit tests?

From Angular 14.1 onwards, the correct way to update input values is to use the `componentRef.setInput()` method. This simulates how inputs are bound in Angular, ensuring the proper behavior for tests.

What should you do if you're using an older version of Angular (prior to 14.1)?

If you're using an older version of Angular, it's recommended to use the **TestHost** strategy. This involves wrapping the component under test in a host component, and updating the inputs through the host component's properties, ensuring proper input binding behavior.

What is the issue with using class names, IDs, or tags as query selectors in unit tests?

Using class names, IDs, or tags as selectors in tests is fragile because these can be easily changed or renamed during component refactoring. This can break the tests without the developers realizing it, leading to unreliable tests.

What is the recommended way to select DOM elements in Angular unit tests?

It's recommended to use `data-*` attributes for selectors, such as `data-testId`, to make them more stable and clearly indicate that the element is used for testing. This makes refactoring easier and ensures that selectors aren't accidentally changed during development.

Why is it a mistake to call component methods directly in unit tests?

Calling component methods directly in unit tests gives a false sense of security because it doesn't simulate real user behavior. Users interact with the component via the UI, so unit tests should simulate these interactions, like clicking a button or changing a form input, to verify the component's behavior accurately.

How can you simulate user behavior in an Angular unit test instead of calling component methods manually?

Instead of calling component methods directly, you should query the corresponding DOM element (like a `<select>` element) and simulate the user's interaction, such as changing the value and dispatching an event like `change`. This ensures the test reflects how the component would be used in real life.

What is the problem with testing component outputs by subscribing to them inside the test?

Subscribing to component outputs inside the test can lead to false positives. If no output is emitted, the expectation function inside the subscription won't be triggered, and the test will incorrectly pass. To fix this, you should store the emitted value in a variable and check the expectation after the value has been updated.

How do you ensure that a test fails correctly when no output is emitted from a component?

To ensure the test fails when no output is emitted, you should store the emitted value in a separate variable inside the subscription callback. Then, move the `expect()` assertion outside of the callback, so if the value is not emitted, the test will fail due to a mismatch with the expected value.

What is Wallaby.js and how can it help with unit testing in Angular?

Wallaby.js is a real-time test runner plugin that integrates with your code editor (like VSCode). It provides immediate feedback on your tests as you write or modify them, showing test results directly in your editor. This tool helps developers catch errors quickly and improve the efficiency of writing and debugging tests.