Writing a good test is not as simple as it sounds, it takes some guidance and practice to get it right. One of the key factors that make a good test stand out is the arrange (or setup) part. For Angular component tests, Single Component Angular Modules (SCAMs) help to make the difference between an OK test and a good test. With SCAMs, you end up with no fragile test setups with half of the code, which results in a happy and productive, team that isn't afraid to move things around.
I'm certain that a previous team that I was a part of could have benefitted from SCAMs to be less frustrated on our component tests. Most changes to a component required some minutes for an experienced developer to make sure that the existing tests were passing again. While a new developer often was staring at the failing tests not knowing what to do next. For most cases, this doesn't make sense because the served component was working. After a few times, the process of fixing the failing test became clearer but it wasn't ideal and it was costly.
SCAMs provide an answer to this problem, in combination with the Angular Testing Library it might even become fun to have tests for your components.
Let's take a look at an example.
Can you think of changes to the
MyAwesomeComponent component that breaks the render process, thus causing the test to fail?
A couple of reasons that I can think of to break the test are:
- a new module is used in the
MyAwesomeComponentcomponent uses a new component
- one of the (grand)children of
MyAwesomeComponentis using a new component
- a used component is removed
MyAwesomeComponentcomponent is added to
To make the tests less brittle to internal changes, we can make use of SCAMs. With a SCAM the changes to the component (or directive) are encapsulated within its module. Because this module is directly imported into the test, the setup of the test is automatically updated.
Without going into too many details of a SCAM, the module of the component under test looks as follows.
Render the component and import its module in which it's declared in.
To prevent the rendered component to be automatically added to the TestBed's declarations, use the
When SCAMs become the de-facto implementation, the
excludeComponentDeclaration property can globally be configured by using the
configure method in the global test setup file.
Now, you can omit the
excludeComponentDeclaration option in each
You can also use the component's template instead of its
Type to render the component.
This doesn't require the
excludeComponentDeclaration property to be set.
While SCAMs have multiple positive features, the benefits that they give to Angular component tests is my favorite characteristic of a SCAM.
From my experience, it's been an absolute joy to work with and I'm feeling more productive than before.
By organizing your Angular building blocks into SCAMs you don't need to figure out which dependencies are required to keep the test setup up-to-date. With SCAMs each change to the component's production code is directly reflected in the test.
If you follow this practice, your tests become resilient to internal changes and you can give your full focus to the new features.
A warm thank you to the contributorsDany Paredes
- Getting the most value out of your Angular Component Tests
- A practical guide to Angular Template-Driven Forms
I appreciate it if you would support me if have you enjoyed this post and found it useful, thank you in advance.