`dart test` failed tests could be on `stderr`

[FMorschel]

I'm testing git hooks for the first time with a Dart package. My current pre-commit script is:

#!/bin/sh

echo "Running pre-commit checks..."

# Basic pre-commit sample code here

# Fetch packages
echo "Running dart pub get..."
dart pub get
if [ $? -ne 0 ]; then
  echo "dart pub get failed."
  exit 1
fi

# Dart analyzer no errors should be found
echo "Running Dart analyzer..."
dart analyze
if [ $? -ne 0 ]; then
  echo "Dart analyzer found issues."
  exit 1
fi

# Dart tests should pass
echo "Running Dart tests..."
dart test . 1>/dev/null
# Print files that failed tests
if [ $? -ne 0 ]; then
	echo "Dart tests failed."
	exit 1
fi

# Dart fix --apply then any changed files should be added to the commit
echo "Running Dart fix..."
dart fix --apply .
git add .

# Dart format then any changed files should be added to the commit
echo "Running Dart format..."
dart format .
git add .

# return 0 to indicate that everything went well
echo "Pre-commit checks passed."
exit 0

If I run the tests this way, I get no output. If I remove 1>/dev/null I get a lot of output even for completing tests.

I wanted to ask if the failed tests could be on stderr, so I could show at least which file didn't pass the testing.

The only other workarounds I could think of would be re-running all tests or running dart test -r json and then parsing the returned JSON somehow.

dart info

#### General info

- Dart 3.2.1 (stable) (Wed Nov 22 08:59:13 2023 +0000) on "windows_x64"
- on windows / "Windows 10 Pro" 10.0 (Build 22621)
- locale is pt-BR

#### Project info

- sdk constraint: '>=2.17.6 <4.0.0'
- dependencies: collection, equatable, intl, time
- dev_dependencies: dart_code_metrics, dartdoc, lints, test, very_good_analysis

#### Process info

| Memory | CPU | Elapsed time | Command line |
| -----: | --: | -----------: | ------------ |
|   0 MB |  -- |              | dart.exe     |
|   0 MB |  -- |              | dart.exe     |

[bkonyi]

cc @natebosch

[natebosch]

I think this would also be solved by #829

I'd be nervous moving existing output from stdout to stderr since it's likely to break existing scraping, but I agree that if we were writing this library fresh I'd consider using stderr for failure output.

cc @jakemac53 - do you feel strongly either way about moving output to stderr? I think I lean towards implementing a failures-only reporter.

[jakemac53]

I do worry it would be too breaking at this time to do this in the default reporter.

We could however add a new reporter which does it (could share an implementation and just configure it differently?).

Or, a failure only reporter would also be fine.

[jakemac53]

Another option could be supporting logging levels etc.

[natebosch]

Having reporters write to two potential outputs is also a much deeper change than a failure output reporter - would probably need to wait for #1311

[FMorschel]

Or, a failure only reporter would also be fine.

That would pretty much be what I was looking for.

[FMorschel]

Should I create a new issue for creating a failure-only reporter and keep this one open, or should I simply rename it to clarify?

[natebosch]

We can discuss the failure-only reporter, and track interest with 👍 etc, over at #829