Am I planning well for the Frontend integration testing?

[Taewa]

Hi all, I came from this post

Our main intention is to write integration test for Frontend for the following reasons:

• Reduce burden from e2e testing
• UI focused testing without concerning Backend issue
• Sharing Business team regarding what will be covered (BDD)

So our choice is using CucumberJs (+ typescript) for the last point BDD. And run testing without running entire Frontend app but a piece of page component. Because we just want to test how certain components react each other in a single page. For example, user has see a popup if user purchased an item. Otherwise no popup..

If we go this way, I don't think Cypress is needed. And I am tried to integrate Karma + Mocha + Chai with CucumberJs (additionally karma-cucumber-js-latest and cucumber-tsflow). And facing a build issue due to the typescript compiling issue with cucumber-tsflow.

After hours of struggling I came up with questions "Am I doing correct way?" and "is this integration test?".

I am wondering how others running Frontend integration test without running full journey. Unit testing and e2e testing were straightforward to me but not integration testing.

Could anyone give me some advice && opinion?

Thanks, Taehwa.

[NoriSte]

Hi @Taewa Integration tests are the hardest ones because the line is subtle and the options are a lot.

Anyway: it really depends on your needs. Reading your notes, I'm not sure if you have a big front-end application (since you cite Cucumber, testing components out of the full front-end application, using TypeScript for tests too) or if you are over-engineering in advance your test suite (because it seems that you're a novice from your words). Which case is yours?

[Taewa]

Hi @NoriSte Thanks for your response.

I'd say our app is mid-large size. (Considering micro Frontend due to the size of app & several different businesses). Using Cucumber is related with size of app? I thought Cucumber is related with BDD. Let me know if I misunderstood your point.

My needs of the integration test is to test only Frontend "page" component if a proper data is given by Backend. However, I feel running mock server and running full user journey for integration feels a bit too much in our case. Our app has sequential steps. If you want to test page 9 (for example), then you have to run the test from page 1 even if you don't need to test it. So we started to think about "how about we import a page component (in this case page 9 component) and give a mock data then start test". By this way, we don't have to run our entire app for the test (this one will be covered on e2e level).

How do you think about this idea?

(At least I am a novice on integration test despite I have been doing unit test and fe-e2e test (wdio))

[NoriSte]

Cucumber is not related to the size of the app but it's quite an intermediate/advanced step for a beginner (but you're not a beginner, I just wanted to be sure about that 😉).

Well, you have some options IMHO:

• you take a snapshot of the front-end state at Page 9 in order to set it directly when the app loads: it works only if the app allows short-circuiting directly to Page 9 if it finds a state that indicates that "the user" has gone through the first 8 steps. This solution is fast but obviously maintain the snapshot has a cost
• you expose a shortcut from every Page 1, Page 2, Page 3, etc. component: doing so you can load the page, call the shortcut from Cypress, Page 2 is loaded, call another shortcut, and so on. You don't have to maintain the snapshot but going to Page 9 could require 3-4 seconds
• expose a shortcut that goes directly from Page 1 to Page 9. Please note that all these shortcuts could be exposed when the app is running inside Cypress
• Your idea could work using Cypress 4.5.0+, have you already read the Components test dedicated chapter?

[NoriSte]

I close the issue because it's been forgotten here open 😊