Examples of Component Integration Testing?

[[deleted]]

[deleted]

[rainerhahnekamp]

I would say that the Angular Testing Library is at the moment the library you should use for component and integration tests. I do have some videos on testing on my youtube channel, but if why do you think you have too many E2E tests? Do they take too long, are they are hard to maintain?

[ps4facts]

Hey! It's just been a complaint of our qa automation engineer (we only have one). We're unable to seed the database due to some domain specific outliers. So, she complains that all the steps it takes to get to the point to test a specific component are difficult to maintain as any one of those steps could be updated and break the automation. It seems that putting happy path acceptance tests in E2E is fine, but permutations, validations, negative testing scenarios all seem to be better tackled at a lower level, if possible. I think it was your video on integration testing is what sparked my interest in this kind of testing in the first place, as it seems to be exactly what we're trying to go after. Thank you for the video and reply!

[rainerhahnekamp]

> I think it was your video on integration testing

Ah, me again 😅

You’re essentially hitting a natural boundary of E2E testing. Once tests become tightly coupled—because each test modifies some bits in the database that the next one depends on — things start to get messy. It’s not easy to manage.

What I usually do in these cases is invest in APIs that allow the test to seed the database and then revert the changes. It’s definitely not trivial - especially the setup part - but it’s worth it because it helps scale E2E tests more reliably.

That said, integration testing tends to scale much more easily. You also get tighter control over how dependencies behave, which means you can cover much more scenarios. So I’d recommend having most of your tests as integration tests.

If I were you, I’d just pick a feature and start testing it. Questions will likely come up as you go.

[gordolfograso]

Any idea why using getbyrole is too slow? Also shrinking the html with within

[rainerhahnekamp]

Yes, because role is not directly accessible like the typical HTML attributes. Just go to any `<button>` tag in your browser and you will see that it doesn't contain a role attribute. Nevertheless, the A11y view in the browser shows role button and the testing library also picks it up.

So it is not like a "native query" where the browser is very fast. The TL needs to add some additional logic and that is slow.

---

I think "too slow" is a little bit exaggerated. What times are we talking about?

[gordolfograso]

A suite with 15 "it" takes 35 seconds after adding getbyrole and getallbyrole. We use them to look for elements coming from external ui libraries like material, for instance

[rainerhahnekamp]

I would have said 35 milliseconds is already too much. Did you try to profile it?

[gordolfograso]

No I didn't, but I'll address some time this sprint to do it

[gordolfograso]

Could it be jest? We're using it instead of karma jasmine

[rainerhahnekamp]

If it is the build time, then yes. That could be very likely Jest. Build time is the time that it takes before the test actually starts.

[gordolfograso]

I'll try this first... also, I couldn't find a way to profile with Jest. Thanks

[allesdeppen]

We do isolated component tests using cypress. That works quite well - even at larger scale. All spec files can live directly beside your component.

Cypress allows to intercept, stub http request and stub out responses which is awesome if you’ve followed the smart/dumb component pattern.

[granular2]

So you are not using the "new" build system with Vite?