Full parameterized tests support #649
Conversation
Pull Request Test Coverage Report for Build 873
💛 - Coveralls |
|
Not sure if i can help - i deleted my fork when it got merged and totally forget about it ... about jest restarting via JestExt.runTest: probably because i didnt know any better ... |
|
@CzBuCHi thanks for the reply. |
|
@stephtr looks like you are busy... I ran with this PR last week, and it seems solid, pretty handy actually, as I started to add more parameterized tests... At this point, I think it's probably better to merge it and cut an alpha release so we can start the field testing/fixing cycle sooner... thoughts? |
| * @param fileName | ||
| * @param testIds test name/pattern. | ||
| * Because a test block can have multiple test results, such as for paramertized tests (i.e. test.each/describe.each), there could be multiple debuggable candidates, thus it takes multiple test identifiers. | ||
| * Noite: If a test id is a string array, it should represent the hierarchiical relationship of a test structure, such as [describe-id, test-id]. |
There was a problem hiding this comment.
Typos ("Noite", "hierarchiical")
| command: `${extensionName}.run-test`, | ||
| title: 'Debug', | ||
| title: codeLens.testIds.length > 1 ? `Debug(${codeLens.testIds.length})` : 'Debug', |
There was a problem hiding this comment.
Let's add a space after "Debug"?
There was a problem hiding this comment.
Is "Debug n failing tests"/"Debug failing test" too long? -- Edit: In some cases that doesn't make sense. It's better to stick to the "Debug (n)" approach.
| id, | ||
| })); | ||
| const selected = await vscode.window.showQuickPick<RunTestPickItem>(items, { | ||
| placeHolder: 'select a test to debug', |
There was a problem hiding this comment.
How about an uppercase "Select"?
|
@stephtr better late than never 😉 ... I will address those in another PR |
This PR adds full parameterized test support across the extension:
test-matching
decorators
diagnosis
debug
Open Questions
JestExt.runTest. Looks like this logic was there since runTest is introduced (debugger support #172). Could not see any discussion about why that was needed... Concern that it could be a very expensive overhead especially for large projects. I tried without stop/start logic and all seem fine. So I figure unless we knew the explicit use case to justify the overhead, it is better to leave them out...Notes
test.eachresults is always 42,9 jestjs/jest#10412). The fix (Fix location fortest.eachjestjs/jest#10413) was merged in jest-26.5.0. Therefore, the minimal jest version for projects with parameterized tests should be >= 26.5.0fixes #427 (see comments)