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

Tests type_variable_bounds4_test.dart have too weak logic #30655

Open
eernstg opened this issue Sep 8, 2017 · 1 comment
Open

Tests type_variable_bounds4_test.dart have too weak logic #30655

eernstg opened this issue Sep 8, 2017 · 1 comment
Labels
area-test Cross-cutting test issues (use area- labels for specific failures; not used for package:test).

Comments

@eernstg
Copy link
Member

eernstg commented Sep 8, 2017

During Dart 2.0 test migration, it became evident that the test type_variable_bounds4_test.dart (which currently exists in language and language_strong and will soon exist in language_2) uses a multi-test logic which is too weak: It surely intends to check that about 10 different situations cause a compile-time error (a static type warning in Dart 1.x), but it will in fact succeed as long as any non-empty subset of them causes an error. In other words, we might fail to have 9 out of 10 expected errors, and nobody would notice. The test needs to use a different multi-test logic such that each error is checked separately.

Here's some code that has nothing to do with the actual test, but which shows the core of the issue:

main() {
  // Let's say we think this should be flagged as an error.
  int x = 42; //# 01: compile-time error

  // We also think this should be flagged as an error.
  x = x + 1; //# 01: continued

  // ... somewhere in the middle, we have a real error.
  by the way, here's a real error. //# 01: continued
}

The intention is that each line marked with //# 01: .. should be flagged as an error, but the effect is that this test succeeds because a non-empty subset of the marked lines actually contains an error. The following would work:

main() {
  // This declaration is expected to cause several usages to incur a compile-time error.
  int x = 42;
  x = x + 1; //# 01: compile-time error
  by the way, here's a real error. //# 02: compile-time error
}

We would then notice that there is no error for x = x + 1, as we should.

We have about 2558 occurrences of continued in test files under tests; it is not obvious whether this is a single exception or the issue may affect several tests.

@eernstg eernstg added the area-test Cross-cutting test issues (use area- labels for specific failures; not used for package:test). label Sep 8, 2017
@eernstg
Copy link
Member Author

eernstg commented Feb 9, 2018

Note that test files containing multiple occurrences of /*@compile-error=unspecified*/ use the same (faulty) logic: If just one compile-time error occurs then the complete test run is considered successful, even though we may have just one actual compile-time error, and all the others are free-riders. As of Feb 2018, the following test files in tests/language_2 have this problem:

factory2_test.dart
factory3_test.dart
field1_test.dart
field_method4_test.dart
on_catch_malformed_type_test.dart
operator5_test.dart
operator_equals_test.dart
regress_12561_test.dart
regress_19728_test.dart
return_type_test.dart
type_inference_circularity_test.dart
type_variable_bounds2_test.dart

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-test Cross-cutting test issues (use area- labels for specific failures; not used for package:test).
Projects
None yet
Development

No branches or pull requests

1 participant