Replies: 2 comments
-
|
Is https://github.com/mbacarella/curses the best library for the job? Does anyone have experience with it? The Curses library won't work on Windows, see https://en.wikipedia.org/wiki/Curses_(programming_library)#Portability. For this reason and to keep dependencies minimal, an interactive extension of Testo should be optional and provided by a extra Opam package as we do for Lwt. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
A non-interactive way of addressing most of the problems would be to export the test data to HTML. Pros:
Cons:
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary: An optional extension of Testo could provide an interactive, text-based interface for listing, inspecting, and approving tests quickly and safely.
An issue is that we often find ourselves with too much or too little output. This has been mitigated by first printing the output of all tests (in either
runorstatus) and then recapitulating by printing only the tests that need attention. This is not good enough when test logs are long because it gets hard to scroll and see the other failing tests. We could add an option to control the verbosity like alcotest's--tail-errorsbut it may not be sufficient.This is related to the general issue of navigating from one test to another. When working on testing a feature, often more than one test is involved. I use
-s Suite_nameto select the tests I'm working on and this part is satisfying. However, I often want to do the following and it's difficult:less. After this, more scrolling up is need to get back to the status of the other tests. At this point, I may re-run./test statuswhich is relatively quick but not ideal. Printing the captured output by default would be too much. We're currently showing diffs but only if the test failed and an approved snapshot exists. If the test is new, reviewing the output is a little tedious../test approve -s IDwhich is more complicated than it could be and error-prone.What if we could navigate tests interactively? We could offer an interface that shows a list of files. There would be options to filter the list of tests by status (e.g. press
fto toggle between failed-only and all tests) or by search text (ID, category, or name). Hitting the right arrow key would take us to the view of a single test. From there, we could expand or collapse different output files of interest, notably the captured output and the uncaptured output (logs).I have no experience in implementing text-based interactive interfaces. It seems difficult. It also seems like something we want here. Please chime in if you have ideas on the feasibility of this.
Beta Was this translation helpful? Give feedback.
All reactions