I understand the tester will test sequentially challenge by challenge. I feel it is good to run test by specifying any challenge. This way we don’t get stuck on a particular challenge, but pause it for a while and proceed to other challenges if it is possible to do logically.
For example in Redis - I should be able to skip extensions and move on to other if I need time to pause it and think about it more deeply
It will be a valuable feature imho
@Jothikumar-ekanath you should be able to toggle extensions btw:
There’s a toggle in the left sidebar that will open up this modal:
All your progress is retained, so you can switch to another and revisit it later if you like.
Does this address your use-case? Or do you still think it’s useful to skip tests even within a particular extension? (I haven’t heard this much before, since each test kind of builds on the other within a specific extension)
Yes, toggle extensions are really great and I definitely like it. In a given extension I definitely think it goes sequential and the challenge follows in some logical order. But the ability to jump to different challenges and run tests for a specific challenge will come handy when we are stuck on challenge and needed more time to think through it (that thinking is what I feel I am learning). BTW, I love this site, thanks for this great product
@Jothikumar-ekanath just curious - was there a specific stage in which you felt this need (i.e. one where toggling extensions wouldn’t have helped)?
In the Redis challenge, I felt some of the stages the instructions weren’t very clear. Because of that I had to try different input combinations to pass the stage.
We go writing code stage by stage. But lot of times we want to refactor the code and when we change things, the older tests fail. I feel like it will give more control if we have the ability to run the test cases only for a given stage and work on it, instead of runnings tests for all the stages at all times. An option to specify that will be helpful
Also, is there a way for users to contribute back on the instructions or writing more test cases ( in cace if you are planning to add that as a feature)
The new --previous option for test works nicely. I’d still like to target individual stages, if only because re-running the whole suite repeatedly slows down iteration and feels wasteful.
Improving the QoL around refactoring would help with users that drop back in after taking a break (I say this as someone who inevitably ends up making dramatic edits after a week off…)
I agree about running test for some random stage. I crossed initial stages in redis and when I wanted to refactor, I wanted to make sure previous cases are still passing. It would be awesome if we could pass arguments like codecrafters test --stage "#RG2" @rohitpaulk
@prathamesh000777 did “codecrafters test —previous” not work for your use-case? Is it problematic because it takes too long?
Wow, love the prompt reply.
Yeah, the only problem would be that it will be slow if you have crossed several stages, which I have not 
and dint face it 
BTW my bad I didn’t run this command until you mentioned it, I was assuming it would run only tests for the previous stage whereas I wanted to run tests for two stages before the current one. I should have read the description for --previous flag properly 
appreciate your efforts, @rohitpaulk I love this platform
I actually would agree that could be helpful to have something like codecrafters test --stage StageID; I am right now on the Redis stage and I have been have some issues time to time with one of previous stages, it fails time to time, and I am trying to debug what is going on there. The only way I have to do this is using previous which is ok, but this makes a bit difficult since I have to run a lot of tests before getting to the one I want, and yes this even though I have disabled some extension already.
PS: Thank you for all the work you have put into codecrafters!
