DEV Community: Piotr Lewandowski

Angular Testing: Avoid done() function

Piotr Lewandowski — Fri, 09 Apr 2021 00:00:00 +0000

Let’s talk about harmfulness of real asynchronicity in tests.

Have you ever encountered random test instability on Continuous Integration? Called some test were just “flaky”? Tests that took 10s instead 10ms? I guess you did! There might be lots of reasons for flakiness of tests. I found asynchronous operations are great contributor to flakiness score.

Here I want to describe mocking async as simple alternative to done() that could avoid many potential build failures.

I’m going to use Observable to simulate asynchronous operations. It is not limited to RxJs though. The article applies to any kind of asynchronous operations under the hood of components and services.

How to check the value produced from Observable, Promise, or callback?

To access variables in the callback, we have to be in its function scope!

it('should be green', () => {
  anyObservable()
    **.subscribe((el) => {  
 expect(el).toBeTruthy();  
 });**  
});

It looks innocent, sometimes even works! When it does not work? Simply when anyObservable goes async and calls subscribe() with small delay.

In above example, test is always green then, because test executes faster than subscribe() callback is called. It’s also green when the value does not match expect().

It’s simply never checked. Just like volkswagen engines emissions test — always green.

When we’re handling asynchronous operation?

Think of any DOM event listeners, HTTP calls, Websockets, animations, own state management events, timers, intervals, Promises and more.

We do lots of async things in our components. It would be unwise if we just assume those things does not affect tests.

To overcome this, frameworks like Jest or Karma provide done() function. It’s a marker for test runners not to finish the test until we call it.

it('should be green for async operation', ( **done** ) => {
  timeout(500)
    .subscribe((el) => {
      expect(el).toBeTruthy();
      **done();**  
});
});

Bingo, isn’t it? So, why do I have the intention to discourage using done()?

Poor assumptions of done()

The example above seems to be correct, but it only works under very specific circumstances. There are some common false assumptions of what the done() function does that lead to this confusion.

🚀 When Observable emits 1000x times in a loop by mistake = test is green
😩 When Observable emits 2x , but the second time it does something different than we expect = test is green
🛑 When Observable errors after first emit = test is green
⌛️ When Observable never emits = test timeouts = slow unit test
🏁 When Observable does complete before first emit = test timeouts = slow unit test

and more…

As you see, even when some situation goes wrong, test is green. When we use done() in callback, we’re not precise. Those are examples of real bugs we found in tests, not a theoretical mumbo jumbo.

Do we always need to use done() in callback?

When callbacks are synchronous , we don’t really need to use expect() inside callback.

it('should be green for sync', () => {
  // given
  **const result = [];**

  // when
  of(1, 2)
    .subscribe((el) => **result.push(el)**);

  // then
  **_expect_(result).toEqual([1, 2]);**
});

✅ When Observable emits 1000x times in loop by mistake = test fails
✅ When Observable emits 2x, but second times it does something different than we expect = test fails
✅ When Observable errors after first emit = test fails
✅ When Observable never emits = test fails
✅ When Observable does complete before first emit = test fails

Wouldn’t it be beautiful if we could just skip asynchronous nature of the events?

// Detect dark theme var iframe = document.getElementById('tweet-1363096314297409537-731'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1363096314297409537&theme=dark" }

How to mock async operations? fakeAsync()

Testing asynchronous code is the more typical. Asynchronous tests can be painful. The best way to handle them? Avoid!

Asynchronous is a side effect, same as a system time clock. We need to avoid them if we want to have a stable and robust test suite.

In Angular, we have absolute genius mock. It makes everything synchronous and controlled from the tests — fakeAsync().

it('should be green for async', **fakeAsync** (() => {
  // given
  const result = [];

  // when
  **interval(1000)**.subscribe((el) => result.push(el));
  **tick(2000)**;

  // then
  expect(result).toEqual([0, 1]);
}));

☝️ Above, we have an interval(1000)emitting new increment every second starting from 0. Typically, we don’t want to wait real 2 seconds to check conditions. For 10 000 tests it means 5 hours of waiting.

Time is frozen. We’re in charge with tick() function. Whenever we want. Whatever amount of time should pass. With precision to millisecond.

Again, everything is synchronous. You just don’t need done() function.

Additional advantages of using fakeAsync()

We won’t forget done() when we don’t use it
Test flow is clear and static— expect() always at the end, always executing
We’re sure we test exactly one async behavior at the time
We won’t make test utterly slow by using real async operations — think of setTimeout for 5 seconds.

Angular with Ivy — Build performance review

Piotr Lewandowski — Tue, 14 Apr 2020 19:58:23 +0000

We have seen various benchmarks and charts on conferences. What is the real impact on our application?

In this article, we’re going to dive into bundle-size and compilation speed insights.

Application context
Bundle size benchmark
- Full build size
- gzipped value does not knock down
- Why is main.js bigger?
Compilation speed benchmark
- Production build
- Development build
- Recompile time
YES!
Unit testing speed
Closing thougts
Bonus: Lesson learned

Discussing how Ivy works is out of our scope. I recommend inDepth article about its internals, for other changes read official blogposts for Angular 9 and Angular 9.1.

Application context

Each application is unique. Hence, Ivy enablement is going to cause different improvements. Because of this, benchmark I created must be spoiled by application we develop. Here are few details about it:

A single Nx monorepo with two apps: Bigger main product and smaller support app, both sharing codebase. We develop this codebase for 2 years.

130k lines of code (TypeScript + HTML)
800 components
140+ lazy-loaded modules

I conducted tests on Angular 9.0.6 with Ivy: enabled and disabled. I compare ES5 and ES2015 bundles where it makes sense. Bundle size is calculated by a webpack bundle analyser.

At the point of writing, we already use Angular 9.1, I’ll put a note where it makes a difference.

Bundle size benchmark

Measurements are based on gzipped vs non-gzipped configuration. To make results easier to analyse, I focus on ES5 builds only.

Angular team suggest expected values:

Small applications: 30% improvement
Medium applications: 2% improvement
Big applications: 25–45% improvement

Full build size

I’m using full build metric for the general sum of improvements delivered by the new compiler.

Full production bundle size Values are Megabytes.

gzipped value does not knock down

Full build metrics does not relief what is going on under the hood. List of files (for us its over 140) splits on main.js file that is loaded as first and 139 lazy loaded modules.

Let’s split comparison:

Comparison of main.js and sum of lazy loaded chunks. Values are Megabytes.

🤯 Why is main.js bigger?

Lazy loaded chunks are purely compiled with Ivy, effecting smaller output of gzipped and minified bundles by 20–30%!

This is good, but what is going on with main.js? It meant to be much smaller because of better tree-shaking of Angular!

Have a look. main.js consist of:

Angular libraries,
utility libraries,
components / services that couldn’t be lazy loaded

Utility libraries have nothing to do with Ivy, the same with Angular Services. What left us: Angular framework and component library.

Let’s go even deeper and compare only those:

Angular library (left), our in-house barista components library. Values are Kilobytes.

That solves a riddle. For Angular 9, each Angular library — framework itself, component libraries, NgRx — needs to be re-compiled now with ngcc tool to run with Ivy runtime. ngcc re-compiles node_modules libs with Ivy compiler. This process might make components little bigger.

Other cause of bigger size I noticed is, with Ivy enabled, much less lazy loaded chunks are generated. For Pre-Ivy bundle we had 143 generated JS files, for Ivy its only 37 files — split by only root lazy-loaded modules. More code lands into main.js too.

This could be related to a breaking change described in Ivy compatibility guide to be fixed by libraries we use, we had suggestion applied in place though without effect.

Is it bad? Well, on chart — maybe. But it’s temporary situation. Initial plan for Angular 10 is to work without ngcc. I believe, once migration period is over those values are going to be much smaller. Here is my reasoning:

Currently libraries are compiled in JIT-mode, then re-compiled with ngcc
Angular 10: libraries are going to publish code compiled by Ivy with AOT
Then, we won’t need compatibility layers for components with ngcc
AOT-compiled output is additional bonus, making libraries even smaller

Compilation speed benchmark

Production build

Production build time in minutes.

Differential loading (ES2015+ES5) build used to be slower for obvious reasons, it needed to generate two packages of the same code. Ivy helps with both builds, saving 1 minute of build time — that’s a nice improvement. Moreover, it reduces gap:

4 instead of 6 minutes for differential loading
3 minutes 40 seconds instead 4 minutes 45 seconds for regular ES5 build

🎉 20–30% improvement!

Development build

Development build time in minutes.

For development build, there is no differential loading. We compile ES2015 or ES5, never both. Here ES2015 is proven to be 10–20s faster.

After enabling Ivy, we see:

ES2015: 1min 25s instead 1min 55s
ES5: 1min 40s instead 2min

🎉 20–25% improvement! 30 seconds gained for every build started 😎

Recompile time

change re-compilation time (minutes)

Re-compilation time depends heavily on the place you’re editing. Smaller, lazy-loaded modules are re-compiling faster than modules inside main.js.

We’ve already observed significant improvements in recompilation times after upgrade to Angular 8.2 (mostly thanks to TypeScript improvements), but yay! Ivy compiler managed to squeeze times even more.

Small, lazy-loaded module: 5–7 seconds instead of 10–12s
Change in HTML in core components: 12–13s instead of 20s

🎉 30–40% improvement! 😲 5s every-change makes a dramatic difference in development experience.

YES!

Those results are worth waiting for, especially we’re at the process of migration to full Ivy potential, and we can expect further improvements.

BUT! I mentioned libraries, those need to be re-compiled with ngcc tool before a build. For us it costs 40–50s for Angular 9.0 and 20–30s for Angular 9.1

Happily, in Angular 9.1, ngcc is smart enough to run on-demand, not every compilation and not every post-install change.

development build time of first run (minutes)

Overhead is going to be visible only on first run after adding/changing dependencies.

Unit testing speed

We have a new TestBed implementation that allows to cache component definitions without the need to re-compile every test run. It’s expected to speed-up by 25–50%.

I cannot comment it as we use jest with preset for angular configuration,

I haven’t seen any difference for our set-up just by enabling/disabling Ivy.

Closing thoughts

You might get impression that results are not worth upgrade.

No! Nothing like that. ngcc adds some overhead both size and speed, but:

After having a thought, I’m happy bundle size is just not worse during migration period. We already gained build time benefits.

I’m thankful for ngcc, so library authors can have versions compatible with Angular 8 and Angular 9.

I’m thankful we’re not going to split community into Post-Ivy and Pre-Ivy era, the way Python 2 vs Python 3 or Angular 1 vs Angular 2+ did. 😉

In the next blogpost, I’ll present a few tips on migrating to Angular 9 and 9.1 with a single-file commit. Wait, is it even possible with all breaking changes? Yes! But you need to act smart.

Bonus: Lesson learned

Don’t expect Ivy project to speed-up much when you have bugs in your build configuration!

The front-end toolset is complex. Even minor dependency might grow your bundle or compilation time. Thus, make sure you’re doing bundle analysis occasionally (preferably, on a regular basis!).

Angular team tries to save every bit of code in runtime, whereas e.g. sass-loader might add megabytes of duplicated CSS just because of a simple mistake in the configuration.

Piotr Lewandowski

@constjs

🚀 technology radar

Just recently 50% of our build time was took by sass-loader plugin. We figured out bug after 1 month of slow-down.

This plugin has potential to save hours of debugging and days of development time 🔥 twitter.com/addyosmani/sta…

19:02 PM - 07 Mar 2020

Addy Osmani @addyosmani
Use webpack? the Speed Measure Plugin measures speed of your build times, plugins and loaders: https://t.co/nTO7OPt3gT ~ see where it's worth optimizing. https://t.co/2wIlVYTyte

What about your projects? Did you perform similar benchmarks? I’d be happy to hear about your results.

If you’ve learned something new, please:

→ use ❤️, 🦄, 👏 button so more people can see this

→ follow me on Twitter (@constjs) so you won’t miss future posts:

Angular - Translate Enums (i18n)

Piotr Lewandowski — Mon, 08 Jul 2019 12:19:05 +0000

Built-in Angular translation engine supports (so-far) only translation within templates, so you might think it's not possible to translate parts of TypeScript like enums.

In fact, it's quite easy if you follow one practice.

Model from server

To make things easy to reason about, let's have a Todo App :)

interface TodoItem {
  name: string;
  state: TodoState;
}

enum TodoState {
  TODO = 'TODO',
  IN_PROGRESS = 'IN_PROGRESS',
  DONE = 'DONE',
}

Usage

@Component({
  selector: 'todo-list',
  template: `
    <ul>
      <li *ngFor="let item of items">
      {{ item.name }} ({{ item.state }})
      </li>
    </ul>
  `,
})
export class TodoList {

  @Input()
  items: TodoItem[];
}

So what is the problem?

{{ items.state }} will produce generated enums values (0, 1, 2... or 'TODO', 'IN_PROGRESS'...)
We need to convert enum value into string, however this has to be within template, not TypeScript

Bad example

Often we tend to create method with switch-case, which is unfortunate because Angular i18n is not aware of those strings, and so - it won't touch them during translation.

// Don't do it
getStateMessage(state: TodoState) {
  switch(state) {
    case TodoState.TODO:
      return 'not started';
    case TodoState.IN_PROGRES:
      return 'started';
    case TodoState.DONE:
      return 'finished';
    default:
      return 'unknown';
  }
}

How to make it translatable?

There is only one rule to follow:

Every string visible in UI has to be put in template

Usually in our team, for complex string calculation (enums, or some text logic) we create new component responsible only for translation.

We're using it widely in our applications, making a clear distinction between screen-logic and text-logic.

Solution #1

@Component({
  selector: 'todo-state-i18n',
  template: `
  <ng-container [ngSwitch]="key">
    <ng-container i18n *ngSwitchCase="todoState.TODO">not started</ng-container>
    <ng-container i18n *ngSwitchCase="todoState.IN_PROGRESS">started</ng-container>
    <ng-container i18n *ngSwitchCase="todoState.DONE">finished</ng-container>
    <ng-container i18n *ngSwitchDefault>not defined</ng-container>
  </ng-container>
  `,
})
export class TodoStateI18n {

  // enum has to be accessed through class field
  todoState = TodoState;

  @Input()
  key: TodoState;
}

And final usage:

@Component({
  selector: 'todo-list',
  template: `
    <ul>
      <li *ngFor="let item of items">
      {{ item.name }} (<todo-state-i18n key="item.state"></todo-state-i18n>)
      </li>
    </ul>
  `,
})
export class TodoList {

  @Input()
  items: TodoItem[];
}

This works only with regular enums, const enum cannot be used within template (at least, not out of the box)
We happily use this practice not only for enums, but also for string manipulations.
You still need to remember to update template when new enum values are added (e.g. TodoState.BLOCKED)

Solution #2 - ICU messages

@Component({
  selector: 'todo-state-i18n',
  template: `
  <ng-container i18n>
    {key, select,
      TODO {not started}
      IN_PROGRESS {started}
      DONE {finished}
    }
  </ng-container>
  `,
})
export class TodoStateI18n {

  @Input()
  key: TodoState;
}

Works with const enums
Useful especially for string enums
Simpler approach, but also supports HTML elements e.g. TODO {<span>not</span> started})
To be secure, you need to write unit tests that checks enum values