mirror of
https://github.com/flutter/flutter.git
synced 2026-02-20 02:29:02 +08:00
367f454a40
Partial work towards https://github.com/flutter/flutter/issues/133190.
Some context, from @zanderso on chat:
@matanlurey:
> For
[`clang_tidy_test.dart`](c020936303/tools/clang_tidy/test/clang_tidy_test.dart),
what is your vision there? I remember we ran into problems with it
actually executing `clang.run()` in too many of the test cases, but I
don't remember (or seem to have written down) what we decided to do 🙂
@zanderso:
> The existing tests are calling `computeFilesOfInterest` and
`getLintCommandsForFiles` and inspecting the results for positive tests
instead of hitting a real clang-tidy invocation. Tests of command line
flags that call `clangTidy.run()` are also testing cases that
short-circuit or fail before making a real invocation. Making it harder
to do a real invocation from a unit test probably requires plumbing a
fake-able ProcessRunner or ProcessManager object through to the
ClangTidy constructor.
---
All this PR does is allow providing a `ProcessManager` (defaults to
`LocalProcessManager`, i.e. `dart:io`) throughout the tool. Then, for
tests, I've implemented a _very_ minimal fake of both `ProcessManager`
and `Process` (it would be nice to share code w/ say, `flutter_tool`,
but lots of work/overhead for very little surface area).
After this CL, no tests in `clang_tidy_test.dart` actually run a
process. This should unblock adding new features (i.e. original intent
of https://github.com/flutter/flutter/issues/133190) without causing
headaches for others/CI?