Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethink the folder structure created by wdi5 #9

Open
petermuessig opened this issue Mar 23, 2024 · 5 comments
Open

Rethink the folder structure created by wdi5 #9

petermuessig opened this issue Mar 23, 2024 · 5 comments

Comments

@petermuessig
Copy link
Member

@vobu - just notice something while checking a reported issue for the ecosystem. When we create a new project for TypeScript, wdi5 adds the webapp/test/e2e folder which includes Node runtime related code. When using this in combination with the ui5-tooling-modules either an excludes must be maintained or better we move non-UI5-runtime code into another folder. This doesn't make sense to have it in the webapp folder, isn't it?

Happy to discuss this with you!

@vobu
Copy link
Contributor

vobu commented Mar 25, 2024

Hi, rationale behind picking webapp/test/e2e/**/* as the default location for wdi5 tests was to adhere to the standard where UI5 puts its Unit- (webapp/test/unit/**/*) and Integration-tests (webapp/test/integration/**/*) in docs and tutorials.
So my first notion wrt TypeScript would be to have an exclude maintained for webapp/test/e2e/**/*. While moving wdi5 TS resources to sth like /test/e2e/**/* might adhere to the TypeScript standards, it would fragment the test file/folder location into /webapp/test/ and /test, eventually confusing users. But this is just my first notion, nothing set in stone here as long as it helps the UI5 developer.
Thoughts @RandomByte @tobiasqueck @Siolto @dominikfeininger @sebbi08?

@dominikfeininger
Copy link

I can imagine that it might be be confusing for all who just use wdi5, not knowing about the Browser and Node part, and/ or have experience with the

test/e2e/**

structure.

@sebbi08
Copy link

sebbi08 commented Mar 27, 2024

Yea, that is tricky.

From an ui5 standpoint, I would expect all the tests to be in the webapp/test folder.

How about adding a ".gitignore" like feature in the ui5 tooling that will automatically add all folders/files with such a file to the excludes. This would make it possible to add it to the WDI5 template code and therefor need no further config by the Developer.

@RandomByte do you think such a feature is possible without too much work ?

@RandomByte
Copy link
Member

You can already exclude resources from the build: https://sap.github.io/ui5-tooling/stable/pages/Configuration/#exclude-resources

Excluded resources won't be available to the ui5-tooling-modules task. However, they are still available in the server. The idea is to exclude runtime resources that are needed during development but unwanted in production. Our general expectation is that webapp only contains runtime resources.

@heimwege
Copy link

heimwege commented May 8, 2024

From an application developer pov I can add the following: our wdi5 (e2e / scenario) tests most probably use more than one (UI-) app (e.g. doing some configuration in the settings app and then use those configurations in another app). So putting them in the webapp/test folder of one specific app seems a bit off. In our repos (CAP Java, so structure contains folders app, db and srv in the root) we put the wdi5 tests in the root folder ("scenarioTests" or "e2eTests" or whatever; the name is not the problem 🐱). But we also have some wdi5 tests that have their own repo because the scenario to be tested contains apps/(micro-)services from different repos.

Regarding the excludes, we currently exclude

      - "**/localService/**" #mockdata for sap-fe-mockserver middleware
      - "**/test/**" #unit and opa5 tests

because these sources are needed in the pipeline to run the tests, but they are not needed in the deployed application.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants