3

I am currently working in a team, which, when I joined them did not do any sort of unit or integration testing.

Over the last 2 years I have bit by bit pushed dotnet unit testing to a point where it is now considered part of day to day workflow. Integration testing have also had a place and are coming up once again as a point of focus which is great. The team generally agrees that dotnet unit tests are definitely worth it and that dotnet integration tests are also a great addition, although they take longer to write and set up.

The area where unit tests are almost non-existent is our angular/UI code. I've pushed for us to add unit tests for re-usable functions, etc, however component unit testing has largely been left alone as both myself and the rest of the team struggle to quantify whether it is worth it or not. A few attempts to add unit testing to the UI have ended up with us writing a bunch of unit tests, however none of us really understood the value.

Just recently, an experienced (and quite openly opinionated) front-end developer joined the team and his opinion is that angular UI unit testing is completely and utterly worthless. I am afraid of simply agreeing with this point of view as this was similar to the team's opinion about dotnet unit testing initially and now they think the opposite.

Question: What do you test in your angular application and how do you think it improves your software quality/stability?

Possible discussion points: Do you have unit tests? If so - what do you test? Components? Services? State? Actual DOM changes? Do you instead have end to end tests? How would you quantify the time(cost) vs benefit?

Any insight/etc would be highly valued!

Thanks!

  • 2
    What do you value about the tests elsewhere in your system (confidence, fast feedback, ...) and why would you not want that for the Angular UI? Unit and E2E tests aren't either/or, you can use the latter to make sure everything works together while the former checks the finer detail. Angular has built-in testing support, see e.g. angular.io/guide/testing; in general, test behaviour through the public API (for components: DOM, @Input/@Output, interactions with injected collaborators). And unless there's a nuance beyond "worthless", that open opinion doesn't seem at all useful. – jonrsharpe May 25 at 14:13
  • 1
    How sure are you that you need unit testing, as opposed to other kinds of testing? Does your angular frontend contain any real logic, does it (re)calculate data, ... or is it more or less a glorified view renderer? What exactly do you want your test to confirm? The general approach is always to define what you want to confirm and then pick the testing strategy that gets you what you want. – Flater May 25 at 15:08
2

Question: What do you test in your angular application and how do you think it improves your software quality/stability?

Components For components that encapsulate UI-logic, i try to cover the behavior of the component.

For example "ListComponent":

This component should list products and highlight a single product by a threshold (price < threshold).

We might to ensure the following things:

  • component is created
  • component shows all elements given in as input
  • component adds the "highlight" class on elements which match the condition

Another example we have "ListControllerComponent":

This component get products from a service and provide a input field for the user, to modify the threshold.

We might to ensure the following things:

  • component creates
  • a attemp to get products is made
  • the input value of the rangeslider is reflected.

If these tests are successful, we can assume that our ui works as we have described. We cover only our own ui logic, we assume the Browser-API's, Angular and the data provided somewhere is valid.

Services For servives which just wrap around HttpClient i wont write a seperate test, but the mock object for this service is decisive for other tests.

ProductModel:

export interface Product {
    id: number;
    name: string;
    price: number;
};

ProductService:

export class ProductService {

  constructor(private http: HttpClient) { }

  public getProducts(): Observable<Product[]> {
      return this.http.get<Product[]>('products');
  }
}

ProductService:

export class ProductServiceMock {

    constructor() { }

    public getProducts(): Observable<Product[]> {
        return of(
            [
                { id: 1, name: 'Product A', price: 4 },
                { id: 2, name: 'Product B', price: 2.66 },
                { id: 3, name: 'Product C', price: 7 },
                { id: 4, name: 'Product D', price: 3 }
            ]
        );
    }
}

Now assume your API changes, the products type does not longer has the field "price" its now called "price1". To apply these changes to your frontend you might want to change your product-model.

And now one value of tests shows up.

  1. The whole test-setup wont run (typescript-error) because ProductServiceMock returns values of mismatching type price !== price1
  2. After you fixed this, you will see that the test "component adds the highlight" will fail.

I think to know which parts of your application needs an adjustment if some major api breaks is a huge win

Alone for this reason its worth to have tests.

A full example is appended. https://stackblitz.com/github/EnricoVogt/testangular

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.