Raathigesh / majestic

⚡ Zero config GUI for Jest
MIT License
7.5k stars 174 forks source link

FR: collapsing sections within the test window #180

Open gregveres opened 4 years ago

gregveres commented 4 years ago

Is this a bug report or a feature request?

Feature request

Version Info

Reproduction Repo

I use a lot of describe blocks in my test to group together tests that test a logical area. For instance, I am testing a navbar component right now that changes based on the type of club that user belongs to and the type of user within that club. So the navbar has to display different menu choices based on the type of user logged in. It also has to display different menu choices based on the options configured for the club. The navbar also has to look different based on the branding for each club.

So there are 3 distinct areas of tests that I have in my unit test file. I enclose each of those in a describe block so I have many levels of describe blocks. I would like to provide a way to collapse describe blocks so that I can focus on the tests I am writing. Here is an example,

describe ('test navbar component) {
  describe ('test menus based on user types) {
    describe ('test menu setup for a regular user') {
    }
    describe ('test menu setup for a club administrator') {
    }
  }

 describe ('test menus based on club types) {
   describe('test club with no courts') {
   }
  ...
  }
}

I would like to be able to click on a describe block name and have it toggle collapse / expand of that block of tests.

And i see that the list of tests gets reloaded quite frequently. I would like it to remember the open /closed state across one of the reloads. It doesn't have to remember the state persistently, just while it is running. I think it would get very annoying if I had closed a bunch of describe blocks, then I edited and saved the unit test file and majestic reparsed the file and "forgot" which blocks were closed. If it did that, it would nullify the usefulness of the feature.

Thanks Greg

Raathigesh commented 4 years ago

It's a very handy feature to have. We could maintain a separate client-side state to keep track of the expanded state based on the name of the block (describe/test/it). Do you think you would be willing to contribute to this feature?

gregveres commented 4 years ago

Yes I was thinking of taking on the task since I learned a bit about the client during my investigation into the other issue. And I like the tool and expect to keep using it long term.

Raathigesh commented 4 years ago

That's awesome. Let me know if I run into any issues so I could help.

gregveres commented 4 years ago

@Raathigesh The TestFileItem has an id that looks something like this: 'U365Jimuvm6kRCwzXKX-r'. Do you know where that is coming from? It seems to be different for the same test each time the page draws.

My test environment has two test files: file 1 and file 2. When I draw the screen for file 1, I get a set of Ids for the describe and it blocks. Then when I switch to file 2 and back to file 1 to draw file 1 again, the ids are all different.

I was hoping that I could use the Id to uniquely identify the test, but it seems that the Id is random. is that coming from graphQL? from the server component somewhere? I don't think it is coming from jest since the test wasn't rerun when I switched between file 1 and file 2.

If you don't know off the top of your head, that's fine. I will investigate. I was just hoping to save a bit of time.

Raathigesh commented 4 years ago

The ID is generated every time the file is parsed. And the file is parsed everytime you switch to that file in the UI.

Raathigesh commented 4 years ago

I wonder whether we could maintain the collapsed state by creating a clientID in the frontend which is essentially the title of the test concatenated with its parent block title.

gregveres commented 4 years ago

I got some time this morning to work on this. My thinking is to tackle this on both the front end and back end. Since you pointed out that the backend always regenerates the id every time the file is refreshed, I started there. With the checkin that I just did (new branch), the backend will re-use Ids for the same elements. It keeps track of the ids that have been assigned already. I keep a cache of ids per describe block so searching for an existing Id only has a small set of strings to search through.

The next step will be harder because I am just learning react. I have a couple of thoughts here. But independant of the approach, I think I need to keep a map of Id => collapse state outside of any UI component. The UI component will update and reference it.

  1. look for a tree control in react and use that to keep track of collapsed / expanded and some how tie into its sense of collapsed to update an independant store of collapsed/expanded state

  2. I suspect this is where redux comes in with global state, but it doesn't seem like you are using it and I dont know redux enough to introduce it. Also that seems like it might be too heavy for what this is.

  3. do something in the existing component and an external id => collapse map. When rendering, look up the map and prune the children if needed.

I should have more time to work on it this weekend.

Raathigesh commented 4 years ago

Thanks for doing this. I will go through the PR by this week and get back to you.

IPWright83 commented 4 years ago

I don't know how far you got with this - but if expand/collapse functionality existed, you could by default start with all describe blocks collapsed (unless there is a failing test within it). This then allows you to quickly navigate to the tests you're interested in.

gregveres commented 4 years ago

@IPWright83 The code is working, Raaghigesh doesn't like the implementation, which I can understand, its his project.

Hmm, I thought I had started the describe blocks as collapsed, but I don't. I also thought I scrolled to the first error, but I don't. I guess it can be improved some more. :)

It isn't quite as straight forward as just collapsing all the describe blocks. I would like the top level describe block to be open if there is only a single top level describe block. My files all have a single describe block with many describe blocks inside. Now that I look at it, I would like the top level describe block to be open and the rest collapsed.

Raathigesh commented 4 years ago

Sorry, @gregveres I never got back to your regarding that collapsible PR. I've been not very active on any of my OSS projects recently but I'll get back to it soon :)

gregveres commented 4 years ago

Anybody who is interested in this feature can use my fork. I have updated my fork to the latest version (1.7.0)