Grouping missing steps after Update to 1.1.155 and on

[Mr-Pearce]

Installed product versions

• Visual Studio: 2022 Professional
• This extension: 1.1.159

Description

Steps to recreate

1. install 1.1.159.
2. run tests
3. see Code Coverage Grouping slider

Current behavior

Grouping is now only (-1) and (0)

Expected behavior

Previously i could set the grouping to 4 or 5

[tonyhallett]

Grouping level is dependent upon the namespace levels.

[Mr-Pearce]

I didn't change my project since yesterday and yesterday I had more. I also have much deph. E.g. Myproject.controllers.models.results

Tony Hallett @.***> schrieb am Di., 15. Feb. 2022, 16:22:

Grouping level is dependent upon the namespace levels.

[image: image] https://user-images.githubusercontent.com/11292998/154092271-1128129c-c27e-41e4-99af-45b8519835bb.png

[image: image] https://user-images.githubusercontent.com/11292998/154092319-d37bceb2-9d58-49bb-9434-b943e357b5de.png

[image: image] https://user-images.githubusercontent.com/11292998/154092399-f60f522a-5f85-4c4d-8bc8-e91005763913.png

[image: image] https://user-images.githubusercontent.com/11292998/154092456-34988213-1022-4d71-a924-9c8c32e87416.png

[image: image] https://user-images.githubusercontent.com/11292998/154092520-e4280139-d3c8-4420-a371-fed4323b6d3e.png

— Reply to this email directly, view it on GitHub https://github.com/FortuneN/FineCodeCoverage/issues/233#issuecomment-1040404497, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGVPIXAZV5FQBOLZ2OAVMLU3JVS7ANCNFSM5OOUCCKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[tonyhallett]

Are the classes fully covered with FCC option HideFullyCovered ?

[tonyhallett]

I cannot see why you would have different behavior to what I see. The report is generated from the coverage results in exactly the same manner - I have no control over the availability of the grouping slider levels.

My only other suggestion is you have multiple test projects and you did not run them all.

[Mr-Pearce]

NamespacedClasses False did the trick. Sorry that i bothered you.

However, I had only made changes in the config after the grouping was gone. So its still weird.

EDIT: WAIT NO that disabled the grouping alltogether... Here is a screen of my settings and coverage

[tonyhallett]

There is a fine-code-coverage / coverage-tool-output folder in you test project directory. Within that you can find index.html and index-processed.html. The first is what we receive from ReportGenerator and the latter has additional functionality added to the first. Only namespacedClasses has an effect on grouping and is necessary for what you are wanting to achieve. Can you open the original and see how that is presented.

[Mr-Pearce]

Strange i just openend the html files and in both i can change up to 5 levels while vs ist stuck in -1 to 0 .

[tonyhallett]

It is a strange one and will not be easy to resolve as I don't think it is possible to debug the WebBrowser control. There has been no JavaScript exception alert either.

Was the window open when you started coverage ?

Obviously your code is not open source but if you could minimally reproduce what you see that would be good.

[tonyhallett]

Have you closed Vs and ran again ? If you can delete the HTML files, close Vs and run again.

[tonyhallett]

It looks like the issue is with the unprocessed report writing to history and reusing it. https://github.com/danielpalme/ReportGenerator/blob/1ec7c2d069c55443488abcb55a004d827cf123a7/src/AngularComponents/src/app/components/coverageinfo/coverage-info.component.ts#L190

I will find a way around this.

[Mr-Pearce]

Have you closed Vs and ran again ? If you can delete the HTML files, close Vs and run again.

Stuff i tried

• Restarted vs,
• deleted bin folder and restarted vs
• deleted just the html files and restarted vs

Was the window open when you started coverage ?

tried it open while testing and closed/reopening after coverage is done.

Obviously your code is not open source but if you could minimally reproduce what you see that would be good.

I made an new Project with kind of the same project structure and some deep classes. But i cannot reproduce the behavior it outside my project.

[tonyhallett]

Can you try this vsix ( zip ).

It removes the saving to browser history that occurs when window beforeunload.

[Mr-Pearce]

Can you try this vsix ( zip ).

It removes the saving to browser history that occurs when window beforeunload.

That version worked with my project and my testproject (just to get sure)👍

[Mr-Pearce]

One Problem gone and here comes the next one. ;) Previously grouping and Filter didn't reset after a test run. With the new version it resets after each run. Prev: Now: (it takes a second)

[tonyhallett]

Ok fixed with this vsix zip but

The behaviour of the unprocessed report that we receive from ReportGenerator is as follows

1. Retrieve settings saved to browser history and use them a) grouping maximum - as determined by your class namespaces b) grouping - that you set by using the slider c) collapsed states - that you set by using the +- icons

2. If no history - calculate grouping maximum

So 1 a) is the cause of the issue you encountered and rectified by removing history.

Basically this state functionality is great if the report is the same.

I have changed the behaviour such that grouping maximum is always calculated grouping comes from state but limited to grouping maximum.

What I have not done and will not be doing any time soon is collapsed states.

So for now you can choose - turn off using collapsed states or continue using.

This is the collapsing code - as you can see it is just order based.

  saveCollapseState(): void {
    this.settings.collapseStates = [];

    let saveCollapseStateRecursive:(elements: CodeElementViewModel[]) => void = (elements: CodeElementViewModel[]) => {
      for (let i: number = 0; i < elements.length; i++) {
        this.settings.collapseStates.push(elements[i].collapsed);

        saveCollapseStateRecursive(elements[i].subElements);
      }
    };

    saveCollapseStateRecursive(this.codeElements);
  }

  restoreCollapseState(): void {
    let counter: number = 0;

    let restoreCollapseStateRecursive:(elements: CodeElementViewModel[]) => void
      = (elements: CodeElementViewModel[]) => {
      for (let i: number = 0; i < elements.length; i++) {
        if (this.settings.collapseStates.length > counter) {
          elements[i].collapsed = this.settings.collapseStates[counter];
        }

        counter++;
        restoreCollapseStateRecursive(elements[i].subElements);
      }
    };

    restoreCollapseStateRecursive(this.codeElements);
  }

Which do you prefer ?

[Mr-Pearce]

Ok fixed with this

Works fine.

Which do you prefer ?

The current behavior looks fine to me 😕 (collapsed are still collapsed after rerun) So i can't really contribute to that question 🤷

[tonyhallett]

The current behavior looks fine to me 😕 (collapsed are still collapsed after rerun)

But if you add / remove a type - the collapsed state is based upon order.

Anyway, I believe I have fixed the collapse state with a name and depth search. Available on the marketplace now.