Comments (8)
it would be nice to have a yaml file coverage_options.yaml
(like lints uses analysis_options.yaml
)
or even better interact through pubspec.yaml
e.g.:
dev_dependencies:
coverage: ^100.0.0
coverage:
ignore:
- '*.g.dart'
- '*.pb.dart'
from coverage.
How widely use used is *.g.dart
format for generated files? We don't use it in protoc_plugin, we use *.pb.dart
.
I agree with @liamappelbe that whether I want to skip generated files or not depends on the use case.
- If I'm using a code generator (e.g. protoc_plugin) then I want to skip generated files. Testing of generated code should be done by the code generator.
- If I'm developing a code generator then I want coverage for generated files as well as I'm testing correctness of those in my package.
In general there will be more of (1) than (2) so ignoring generated files might make sense, but we should make sure code generators use a common suffix like .g.dart
for generated files. Currently protoc_plugin does not do that (uses .pb.dart
). If not then the default will be useless for some of (2) as well.
Either way we should have a flag for arbitrary globs.
If we ignore some files by default then the design of flags gets a bit more complicated as we will probably also need a flag to not ignore anything by default, or have a flag that is opposite of ignore-file (maybe allow-file).
If we don't ignore by default then one flag for ignoring files will do.
I say we don't ignore by default to keep things simple for now. If we want to ignore some files by default in the future it will be the same breaking change when we add it now.
from coverage.
I wonder if we should glob *.g.dart
by default? Is there value in getting coverage info for generated code? Would excluding it by default be unexpected / surprising for users?
They would have the cli flag to disable the behavior if it was undesired.
from coverage.
I think I would find that surprising, if I was a user. In package:wasm I'd want to disable that behavior. I think the distinction is between users who have generated code that was generated by a 3rd party tool (eg protos), or generated by a tool that is part of the package (which is the case in package:wasm). The former case is probably more common, but in the latter case changing this default behavior would be a confusing breaking change.
As for whether we just add a flag to exclude *.g.dart
, or add a flag that excludes arbitrary globs, I think it's probably going to be the same amount of work either way, so I'm inclined to just do the more general arbitrary glob approach.
from coverage.
I'm in favor of a flag which allows arbitrary globs.
from coverage.
How widely use used is *.g.dart format for generated files? We don't use it in protoc_plugin, we use *.pb.dart.
It's the main convention I believe. IIRC the analysis server relies on that file pattern to know to only report one issue for a missing import, instead of hundreds for the rest of the file (for type not found, ...).
If we had a default pattern here, I would default to that one.
Either way we should have a flag for arbitrary globs. I say we don't ignore by default to keep things simple for now. If we want to ignore some files by default in the future it will be the same breaking change when we add it now.
+1
from coverage.
Related Issues (20)
- Function inside function HOT 3
- Add a benchmark to github CI HOT 1
- Which license is used in this project? HOT 1
- Speed up --function-coverage
- Running coverage in new flutter project HOT 1
- --test param throws error when args are added (--test="test --concurrency=1") HOT 1
- incorrect branch and line coverage with const values HOT 1
- Add `--fail-under` option
- LCOV relative paths HOT 1
- No Coverage Generated
- Fix BRDA syntax in lcov files HOT 3
- Enable firehose for publishing from GitHub actions
- Clean up old SDK/VmService checks
- Tests with `Isolate.run` pause indefinitely. HOT 6
- Ignore like `// coverage:ignore-start` does not work HOT 1
- bug: `format_coverage` does now work when invoked with `dart pub global run`
- cover code for kIsWeb condition true and false both cases
- Test coverage doesn't work when using pattern matching to destructure a record HOT 1
- How to run coverage for multiple packages in a mono_repo HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from coverage.