Closed wesleylhandy closed 3 years ago
wired, because i don't think there was a change related to this and it clearly comes from the parser.
can you make and example of how you use the describe function?
Here is an example of how I regularly write components and use jest (which has no problems at all from the command line by the way, nor from automation, nor from devops!). Below that I discuss the changes within JestRunner that are probably at fault.
test-component.tsx
import React from 'react';
export interface TestComponentProps {
testId?: string;
}
export function TestComponent(props: TestComponentProps): JSX.Element {
return <div data.testid={props.testId} />
}
test-component.spec.tsx
import '@testing-library/jest-dom/extend-expect';
import React from 'react';
import { render, RenderResult, screen } from '@testing-library/react';
import { TestComponent, TestComponentProps } from 'path/to/test-component';
function renderTestComponent(props: Partial<TestComponentProps> = {}): RenderResult {
return render(
<TestComponent testId={props.testId} />,
);
}
describe(TestComponent, () => {
it('renders TestComponent', () => {
renderTestComponent({ testId: 'test-component' });
expect(screen.getByTestId('test-component').toBeInTheDocument();
});
});
Keep in mind, when I first install the extension at the beginning of the year, I didn't have this problem. Then in April sometime it stopped working, so I started using strings. But when it comes to refactoring large projects, its adds difficulty when renaming a Component or method, since most IDEs allow you to smartly rename a variable across a project. But if the value is stringified, it's not recognized as a variable.
The only thing that has changed between v0.4.35 and 0.4.39 is how you escape and push paths
to the args
array. This must be the culprit. It's not reading the describe block correctly and thus must be passing a weird value to the parser
.
src/jestRunner.js
-args.push(quoter(normalizePath(escapePlusSign(filePath))));
+args.push(quoter(escapeRegExpForPath(normalizePath(filePath))));
src/util.js
export function escapeRegExp(s: string): string {
- const escapedString = s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'); // $& means the whole matched string
+ const escapedString = s.replace(/[.*+?^${}<>()|[\]\\]/g, '\\$&'); // $& means the whole matched string
return escapedString.replace(/\\\(\\\.\\\*\\\?\\\)/g, '(.*?)'); // should revert the escaping of match all regex patterns.
}
+export function escapeRegExpForPath(s: string): string {
+ const escapedString = s.replace(/[*+?^${}<>()|[\]]/g, '\\$&'); // $& means the whole matched string
+ return escapedString.replace(/\\\(\\\.\\\*\\\?\\\)/g, '(.*?)'); // should revert the escaping of match all regex patterns.
+}
can you clone the project change the line in jestRunner.js and check if its working again ?
just clone, npm install, run start debugging, open you project.
Sure. Let me check on that tonight when I get home after work.
after some debugging i found that its not at all related to the filepath escaping, instead its really and issue in the jest-editor-support parser, which was fixed in the next version.
i reproduced your example and it was working for me, please check v 0.4.40
Thanks @firsttris . I was actually debugging this at the moment. I concur that the issue was not with the logic of the extension, but rather in the dependency version. Everything I tested, at every breakpoint, the __unsupported__
test name was being returned from the parse
command. All the regex in jest-runner seemed to be working as expected.
I looks like jest-editor-support
address parsing issues in their last two commits: here and here
I just downloaded v0.4.40 and ran the debugger. It works like a charm. Updating the dependency was the fix.
Thanks!
As of v0.4.39, Jest Runner no longer accepts method name, (again), instead returned
__unsupported__
as the parsed test name. See https://github.com/firsttris/vscode-jest-runner/issues/177