jest-decorated incorrectly displays tests

[WeslyG]

Environment

1. vscode-jest version: 4.2.1
2. node -v: v16.13.0
3. npm -v or yarn --version: 1.22.17
4. npm ls jest

├── [email protected]
└─┬ [email protected]
  └── [email protected] deduped

5. your vscode-jest settings if customized:

"jest.autoRun": "off",
  "jest.testExplorer": {
    "enabled": true,
    "showClassicStatus": true,
    "showInlineError": true
  }

6. Operating system: windows11 with wsl2

cat /etc/os-release 
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2021.3"
VERSION_ID="2021.3"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"

Background

I use https://github.com/vitalishapovalov/jest-decorated to write my tests in the form of decorators. However, vscode-jest does not want to display my tests correctly in the source code text.

Prerequisite

• see screen

Steps to Reproduce

see my repo for detail https://github.com/WeslyG/vscode-jest-issue

Expected Behavior

I expect that the green jackdaw in the test using decorators will be on line 7, not on line 14

Actual Behavior

The green test jackdaw flies down to the end of the file

[connectdotz]

interesting... basically the code parser that looks for describe/test blocks failed to recognize the decorated keyword...

While it might be simple to add the extra keywords for the parser (in jest-editor-support), I wonder if it is scalable... Should we be adding keywords for every 3rd party library that replaces/wraps the original jest keywords...? The answer is obviously no...

But maybe we could instead a "mapping" settings that users can pass in to customize the keywords pool..., such as jest.parser.tokenAlias={'test': '@Test', 'describe': '@Describe'}

[WeslyG]

It doesn't seem to work as expected. I tried to make these changes myself in the just-editor-support package and realized that the ast processing is apparently looking for the function name, so it does not respond to the decorator. It seems that these parameters will not work. I didn't spend enough time on this today, and I'll be glad if I misunderstood the code and it can be made to work.

[connectdotz]

@WeslyG

I see... you are right, we only needed to parse functions before. To support decorators, we will need to parse class elements in addition... while the mapping is still needed, the parser logic needs to expand for class elements first, which is not as trivial as I originally hoped but can be done nevertheless. If you are interested, I can work with you.

[WeslyG]

yes, it's interesting to me, but I can't find a good solution for determining when to look for a class and when to look for a function. At first I thought to search for a class only if the search pattern starts with the @ symbol, but it seems this is not the best idea. Maybe it's worth looking for a class in case the function is not found, I'm not sure yet, any thoughts?

[connectdotz]

@WeslyG great! I would start from getNameForNode. Add another condition to check for 'ClassDeclaration' (note it could be wrapped within 'ExportNamedDeclaration' etc).

In searchNodes you will need to recursively parse the class body also.

Basically, look for isFunctionCall and expand the logic accordingly...