Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved reporter experience #2500

Open
novemberborn opened this issue May 25, 2020 · 6 comments
Open

Improved reporter experience #2500

novemberborn opened this issue May 25, 2020 · 6 comments

Comments

@novemberborn
Copy link
Member

By default it provides minimal output. We show a spinner and the status of the last test, so you get a sense of activity, and once an entire test file completes do we print failures. In verbose mode, we'd print the results of all tests & hooks, including logs. Various counts for passing and failing tests are always shown at the end of the output.

If a TTY is not available, we wouldn't print a spinner and only write the appropriate output for a test file once it completes.

We'd use ink to construct the output.

@novemberborn
Copy link
Member Author

This is sort-of blocked by the consolidation of our current reporters, see #2217.

@stavalfi
Copy link
Contributor

stavalfi commented Jan 12, 2021

Feature Request

Background

I'm migrating a Jest project to Ava and I find it hard to search the failed tests in Ava reporter.

With jest, you can search in the terminal "fail " (with a space at the end) and you will find all the failed tests files which failed. (it won't help you to find the actual tests which failed).

With Ava, I need to search for: "✖" symbol to find the actual tests which failed (but it won't help you to find the failed test files).


Problem

In a project with 20+- tests it can be ok. but in my project I have 150+ tests and each one has a lot of logging (with t.log). so the test output is too long to find what I'm looking for.


Feature Request

At the end of the in the default reporter, list the following:

  1. a list of all failed test files.
  2. for each failed test-file, list all the failed tests titles.

Possible workaround

working locally with custom tap reporters is annoying because I need to pipe every command with them every time.

@novemberborn
Copy link
Member Author

@stavalfi I think that matches with what I'm hoping we can get to. Essentially the final output is test files and the results of the tests therein, with any realtime stuff happening just at the bottom of the terminal. So you could follow the output as AVA is running.

@stavalfi
Copy link
Contributor

@novemberborn Thanks for your ongoing effort on Ava. You guys do amazing job.

If that's ok from you, I would like to talk about prioritising this ticket over others.


I'm considering to use Ava in my personal and company projects because of 2 reasons: t.log and better tests concurrency.

Ava has a killer feature: t.log. this feature does not exist in any other test-runner in node (As I'm aware of).
It's such a great feature that when you have tons of logs per test, you can finally do something when the CI/CD fails because the logs are organised per test-title. As to other test runners, all the logs are interleaved and un readable. as a result, some developers will try to reproduce the failed test locally but sometimes fail to do so (due to different environments and so on...)

First of all, I think that this feature (t.log) should have better advertisement in the README.md page. it truly deserves it. good work.

Some of the company project has tons of e2e tests which has tons of logs.

I have made a small POC with Ava and the result is this:
image

The results are: I simply can't find the failed tests / test-files.

I think there should be a balance between what a test runner can provide (features: concurrency, isolation, ...) and ease of use.

My personal opinion about Ava is that the first overcome the latter (by far) in this scenario.

I'm not a developer of Ava but I do consider this conversation as a (pretty) small contribution.

It will be great if you can reconsider priorities this ticket higher.

Thanks for the great work!

@novemberborn
Copy link
Member Author

Thank you @stavalfi!

In terms of prioritization, there's what I can pick up in my spare time, and there's what others contribute. The fastest way for this to happen is for somebody to start the work, and I'll always prioritize helping contributors over doing coding myself.

@novemberborn
Copy link
Member Author

That's just AVA, but with a wrapper so we can use it from inside the package repository. There's a secret environment variable which give the test harness access to the internal status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants