[cq] Using `TestCode` and `normalizeSource` for quick-fix tests
This change introduces `TestCode` and `normalizeSource` into the tests for quick fixes. The goal is to add these capabilities to `AbstractSingleUnitTest`, allowing a future update to replace offsets in tests with markers.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
late List<TestCodePosition> testCodePositions;
I think it would be better to just keep the `TestCode` instance around rather than to destructure it. In other code I've been calling it the `parsedTestCode` to prevent a name conflict.
There is one other issue: this is not the only place that `testCode` is assigned a value. I think we need a way to ensure that `testCode` and `parsedTestCode` are always either both `null` or both non`null`. I tried doing that by wrapping the field in a getter and setter, but that doesn't work either (and is how I know that there are other places where a value is assigned to `testCode`.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Auto-Submit | +1 |
I think it would be better to just keep the `TestCode` instance around rather than to destructure it. In other code I've been calling it the `parsedTestCode` to prevent a name conflict.
There is one other issue: this is not the only place that `testCode` is assigned a value. I think we need a way to ensure that `testCode` and `parsedTestCode` are always either both `null` or both non`null`. I tried doing that by wrapping the field in a getter and setter, but that doesn't work either (and is how I know that there are other places where a value is assigned to `testCode`.
I've refactored more things and ran locally all analyzer tests from test_all. It seems fine now, WDYT?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I think the changes related to adding `TestCode` mostly look good, but I think the bigger issue with our test framework is the fact that it assigns to `testCode` in places where it shouldn't.
The base class (`AbstractSingleUnitTest`) was designed with the assumption that there would be a single compilation unit in the tests. That assumption allows the code in a single test method to be shorter and cleaner than it otherwise would be, but at some point the assumption was violated (by getting tests added that used multiple compilation units). In order to make those tests work some hacks were added that are making it harder to do the cleanup that this CL is aimed to facilitate.
But I think that the larger cleanup will be easier if we address the underlying issue first. I've put together a CL that mostly cleans up the code (https://dart-review.googlesource.com/c/sdk/+/415700). It doesn't completely address the issues in `getResolvedUnit`. I decided to save those for a later CL in order to keep this first CL smaller.
String get parsedTestCode => _parsedTestCode;
I wasn't very clear in the issue, in part because I was expecting that I'd do the work. I don't mind that you took it on, I just didn't add more detail because I wasn't expecting you to. My plan is to add
```dart
late TestCode parsedTestCode;
String get testCode => parsedTestCode.code;
```
In other code I've been using `parseTestCode` to mean the instance of `TestCode`, not the version of the test code that has the markdown removed.
Also, I'd like to do more unification, and having the same name for the code being tested will probably simplify that.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Auto-Submit | +1 |
I wasn't very clear in the issue, in part because I was expecting that I'd do the work. I don't mind that you took it on, I just didn't add more detail because I wasn't expecting you to. My plan is to add
```dart
late TestCode parsedTestCode;String get testCode => parsedTestCode.code;
```In other code I've been using `parseTestCode` to mean the instance of `TestCode`, not the version of the test code that has the markdown removed.
Also, I'd like to do more unification, and having the same name for the code being tested will probably simplify that.
Ohh, I see. It's fine. This also helped me find all the calls to the original setter. Renaming them accordingly.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Auto-Submit | +1 |
String get parsedTestCode => _parsedTestCode;
Felipe MorschelI wasn't very clear in the issue, in part because I was expecting that I'd do the work. I don't mind that you took it on, I just didn't add more detail because I wasn't expecting you to. My plan is to add
```dart
late TestCode parsedTestCode;String get testCode => parsedTestCode.code;
```In other code I've been using `parseTestCode` to mean the instance of `TestCode`, not the version of the test code that has the markdown removed.
Also, I'd like to do more unification, and having the same name for the code being tested will probably simplify that.
Ohh, I see. It's fine. This also helped me find all the calls to the original setter. Renaming them accordingly.
Did you mean `parseTestCode` or `parsedTestCode`? You used both names on the comment. Just to be sure.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
String get parsedTestCode => _parsedTestCode;
Felipe MorschelI wasn't very clear in the issue, in part because I was expecting that I'd do the work. I don't mind that you took it on, I just didn't add more detail because I wasn't expecting you to. My plan is to add
```dart
late TestCode parsedTestCode;String get testCode => parsedTestCode.code;
```In other code I've been using `parseTestCode` to mean the instance of `TestCode`, not the version of the test code that has the markdown removed.
Also, I'd like to do more unification, and having the same name for the code being tested will probably simplify that.
Felipe MorschelOhh, I see. It's fine. This also helped me find all the calls to the original setter. Renaming them accordingly.
Did you mean `parseTestCode` or `parsedTestCode`? You used both names on the comment. Just to be sure.
Sorry for the typo. I meant `parsedTestCode`.
This also helped me find all the calls to the original setter. Renaming them accordingly.
All of the calls to the original setter (except one) will be gone after my CL lands, so I'm a bit confused as to why you'd rename them.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
String get parsedTestCode => _parsedTestCode;
Felipe MorschelI wasn't very clear in the issue, in part because I was expecting that I'd do the work. I don't mind that you took it on, I just didn't add more detail because I wasn't expecting you to. My plan is to add
```dart
late TestCode parsedTestCode;String get testCode => parsedTestCode.code;
```In other code I've been using `parseTestCode` to mean the instance of `TestCode`, not the version of the test code that has the markdown removed.
Also, I'd like to do more unification, and having the same name for the code being tested will probably simplify that.
Felipe MorschelOhh, I see. It's fine. This also helped me find all the calls to the original setter. Renaming them accordingly.
Brian WilkersonDid you mean `parseTestCode` or `parsedTestCode`? You used both names on the comment. Just to be sure.
Sorry for the typo. I meant `parsedTestCode`.
This also helped me find all the calls to the original setter. Renaming them accordingly.
All of the calls to the original setter (except one) will be gone after my CL lands, so I'm a bit confused as to why you'd rename them.
I renamed them because I misunderstood your comment on the issue.
confused as to why
The reason (of why) it helped me, was that I could then open all of the files one by one to review (easier than by reference). This helped me find `pkg/analysis_server/test/src/computer/type_hierarchy_computer_test.dart` for example. But its all fine now. renamed as you asked.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Auto-Submit | +1 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
String _testCode = '';
I don't think there's any value to keeping a cached copy of `parsedTestCode.code` in a field. The getter can just return the value from `parsedTestCode`. Not having the field would prevent anyone from attempting to set `_testCode` directly, reducing the change of bugs in the test framework.
if (value == testCode) {
I thought about adding a test like this, but decided that it would be better to fail the test if we ever try to set the contents of the test file more than once (rather than allowing it to happen as long as the content hasn't changed). (And also, the `value` is expected to be the pre-parsed source, not the source after markup has been removed, so I think the test is wrong.)
I was planning on doing that by making `parsedTestCode` be nullable (instead of late) and failing here if it was non-null when this method is called.
Doing what I had planned would have the unfortunate effect of requiring null checks in lots of places, so I also considered making `parsedTestCode` be a getter backed by a nullable field (`_parsedTestCode`) that throws if the field hasn't been assigned. That might be cleaner.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Auto-Submit | +1 |
I don't think there's any value to keeping a cached copy of `parsedTestCode.code` in a field. The getter can just return the value from `parsedTestCode`. Not having the field would prevent anyone from attempting to set `_testCode` directly, reducing the change of bugs in the test framework.
Done
I thought about adding a test like this, but decided that it would be better to fail the test if we ever try to set the contents of the test file more than once (rather than allowing it to happen as long as the content hasn't changed). (And also, the `value` is expected to be the pre-parsed source, not the source after markup has been removed, so I think the test is wrong.)
I was planning on doing that by making `parsedTestCode` be nullable (instead of late) and failing here if it was non-null when this method is called.
Doing what I had planned would have the unfortunate effect of requiring null checks in lots of places, so I also considered making `parsedTestCode` be a getter backed by a nullable field (`_parsedTestCode`) that throws if the field hasn't been assigned. That might be cleaner.
And also, the value is expected to be the pre-parsed source, not the source after markup has been removed, so I think the test is wrong
This was before your change to `getResolvedUnit` sometimes the resolved unit was brought from the file and it was written without the markdown on disc so this would be it.
Refactored. Care to run the bots again please? Thanks!
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Auto-Submit | +1 |
The left over late I removed makes the tests pass. Completely missed it when I used `Encapsulate Field`. Now the tests pass. Can I please get your review now here too @pquit...@google.com? Thanks a lot!
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
Commit-Queue | +2 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
Commit-Queue | +1 |
Note that this should fix the failures on the Windows bot, so we'd like to get it landed fairly quickly.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[cq] Using `TestCode` and `normalizeSource` for quick-fix tests
This change introduces `TestCode` and `normalizeSource` into the tests for quick fixes. The goal is to add these capabilities to `AbstractSingleUnitTest`, allowing a future update to replace offsets in tests with markers.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |