-
Notifications
You must be signed in to change notification settings - Fork 24
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
[vrotest,vrotsc] (#461) Configurable unit tests setup #465
base: main
Are you sure you want to change the base?
[vrotest,vrotsc] (#461) Configurable unit tests setup #465
Conversation
…rk configuration.
… tests framework.
…onfiguration per package type for configurable unit test framework.
Reading details from the project pom file, generating the needed files and storing them in the project root directory for persistent unit tests configuration.
It will remain a part of the build tools runtime process, not the triggered tests process.
Added some details for the unit test framework configuration.
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
1 similar comment
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
const setupFramework = hasCustomTestsConfig | ||
? undefined | ||
: ( | ||
flags.testFrameworkPackage === "jest" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering whether it is worth converting this logic to a switch case and putting it in a function so that it is easier to extend down the line if we introduce more frameworks.
that being said, I don't think that we will introduce another test framework soon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or even better we could convert that to a factory. I was thinking of changing this to a factory either way so I could definitely do that, I didn't because I can't see introducing support for another framework as well and don't want to add more complexity to the code if not necessary... So I would appreciate your point of view as well and we can apply changes as we decide collectively :)
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
1 similar comment
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
1 similar comment
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
Co-authored-by: Venelin Bakalov <[email protected]> Signed-off-by: Plamen Boychev <[email protected]>
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
1 similar comment
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
1 similar comment
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
1 similar comment
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
Added the required missing "projectRoot" parameter.
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
1 similar comment
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
Indicating what is supported as runner options for running unit tests.
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
1 similar comment
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
1 similar comment
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
1 similar comment
@pboychev-bcom, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding
|
Take a look at: there is a transformer
if (callArgs.length !== 2) {
return false;
}
if (callArgs[0].kind !== ts.SyntaxKind.StringLiteral) {
return false;
}
if (callArgs[1].kind !== ts.SyntaxKind.ArrowFunction && callArgs[1].kind !== ts.SyntaxKind.FunctionExpression) {
return false;
} The first will check if the "describe" has exactly 2 arguments, I believe this should be changed to 2 or more, as that's a possibility in jasmine. The other 2 validate the inputs, these seem ok, as long as the major frameworks agree on the standard. |
Instead of having The template folders should be put outside of the |
I wonder if we can go without the logic of specifying the versions, of the different libraries and dependencies, in the |
NOTE:
Will update the description later. Opening the PR for early peer reviews.
Description
Checklist
Fixed #XXX -
orClosed #XXX -
prefix to auto-close the issueTesting
Release Notes
Related issues and PRs