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

Build CLI sys: detect jasmine tests #2099

Closed
DmitryAstafyev opened this issue Sep 20, 2024 · 0 comments · Fixed by #2101
Closed

Build CLI sys: detect jasmine tests #2099

DmitryAstafyev opened this issue Sep 20, 2024 · 0 comments · Fixed by #2101
Assignees
Labels
new newly created issue

Comments

@DmitryAstafyev
Copy link
Collaborator

DmitryAstafyev commented Sep 20, 2024

In the context of Jasmine, tests, which should be executed should be detected by filename pattern or by configuration file.

Motivation

As soon as developer adds new Jasmine test, it should not require changes on Build CLI sys.

Way 1. By configuration file

We already have the configuration file application/apps/rustcore/ts-bindings/spec/defaults.json. An additional config file will add useless complexity. At the same time defaults.json doesn't have references to spec files. An additional field with the name of spec file could resolve this issue.

Issues/problems/weak points:

  • defaults.json supports comments. In the context of Rust it means, that before opening and parsing of file, we should cleanup file from comments.
  • changing of format defaults.json requires changes of build CLI tool.

Way 2. By file name

We also can list all *.spec.ts / *.spec.js and run tests for just each file.

Issues/problems/weak points:

Some tests like session.benchmark.spec.ts should not be run in a regular way. A possible option - make a naming convention (one of):

  • *.regular.spec.ts - always run;
  • *.ignore.spec.ts - ignore, required direct run

Also we can put spec files into different folders:

  • regular - run in regular way with testing
  • custom - can be run only directly

An addition configuration file is better to avoid.

My vote for Way 2, but any ideas are welcome.

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

Successfully merging a pull request may close this issue.

2 participants