You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Goal: to make it super lightweight to make a new test case so that you don’t think twice about it, while keeping them robust enough not to rot if we rework internals
New command cursorless.recordTestCase, which asks for a test case name / maybe directory
Waits for next cursorless command
On next cursorless command, takes a snapshot of current file, including cursor locations, visible lines, file type, and relevant decorations
Takes snapshot after cursorless command, including cursor and visible lines
Saves before, command, context, and after as a test case
Then add code that can parse this type of fixture and run it as a test
I'd argue that cursorless command should be captured pre-inference, but don't feel strongly
This technique can be used for testing transformations, inside / outside, actions, etc
For example, to check whether the delimiter / inside outside stuff is working for eg "type" transformation, can run the command with "take" and "Chuck". This makes it robust to changes in internal representations, at the expense of being slightly less granular
Also save highlights to make sure those don't break?
Goal: to make it super lightweight to make a new test case so that you don’t think twice about it, while keeping them robust enough not to rot if we rework internals
New command
cursorless.recordTestCase, which asks for a test case name / maybe directoryWaits for next cursorless command
On next cursorless command, takes a snapshot of current file, including cursor locations, visible lines, file type, and relevant decorations
Takes snapshot after cursorless command, including cursor and visible lines
Saves before, command, context, and after as a test case
Then add code that can parse this type of fixture and run it as a test
I'd argue that cursorless command should be captured pre-inference, but don't feel strongly
This technique can be used for testing transformations, inside / outside, actions, etc
For example, to check whether the delimiter / inside outside stuff is working for eg "type" transformation, can run the command with "take" and "Chuck". This makes it robust to changes in internal representations, at the expense of being slightly less granular
Also save highlights to make sure those don't break?
could then also use these test cases to automatically record GIFs (Make GIF generator using existing test cases #215)
let's use this one to capture Add type transformation #32 (comment) as a test case
Extra credit is:
Follow-on issues filed: