Skip to content

Conversation

@T-Gro
Copy link
Member

@T-Gro T-Gro commented Nov 14, 2022

This is a movement of a suite testing a full signature roundtrip:

  • Start with an .fs/.fsx implementation file
  • Autogenerate a signature for it
  • Compile the original file together with the signature

When doing this, two new issues regarding signature generation were opened.
The tests used to work by invoking fsc.exe, is now done in memory using component tests.
Also, the verification in the older suite most likely did not catch compiler issues, because I had to fight many.
This is now captured in the test assert, that compilation must succeed.

@T-Gro T-Gro requested a review from a team as a code owner November 14, 2022 19:43
Copy link
Contributor

@psfinaki psfinaki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good stuff, great job. Put a few small remarks, of course, there is probably a lot that can be improved (e.g. inconsistent casing) but this is not the point of the PR.

Food for thought - I'm currently splitting Editor.Tests into a separate project, have you considered splitting this into a separate project as well? "Component tests" are quite bloated, to the level the name of the project doesn't tell much anymore.

@T-Gro
Copy link
Member Author

T-Gro commented Nov 15, 2022

Good stuff, great job. Put a few small remarks, of course, there is probably a lot that can be improved (e.g. inconsistent casing) but this is not the point of the PR.

Food for thought - I'm currently splitting Editor.Tests into a separate project, have you considered splitting this into a separate project as well? "Component tests" are quite bloated, to the level the name of the project doesn't tell much anymore.

Personal opinion -
Unless it will be crystal clear which test project exists for which compiler feature, I am strongly against new test projects.
It then leads to the situation where "signature file related tests" are spread across multiple projects, without a clear idea where new test code should go (because the established frameworks and helpers provide slightly different functionalities). And we did see incoming commits even to some of the more older test projects, yes.

For a very independent set of features, say "Tests for VS tooling", it might make sense if all existing tests are moved to a single place as well (even if just copy pasted using their existing mechanisms)

@T-Gro T-Gro enabled auto-merge (squash) November 15, 2022 12:40
@T-Gro
Copy link
Member Author

T-Gro commented Nov 15, 2022

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@vzarytovskii
Copy link
Member

"Component tests" are quite bloated, to the level the name of the project doesn't tell much anymore.

I don't think it's bloated, and I don't personally think that it should be split into separate projects.

The purpose of the suite is to have "blackbox-style" tests for compiler as component. It includes testing interop, signatures generation, refassembles, and all other compiler features. It may need some restructuring when other tests are moved here, but not separation, as it will, in my opinion, lead to even more confusion on where certain new test should reside.

@T-Gro T-Gro merged commit 8196f82 into dotnet:main Nov 15, 2022
@T-Gro T-Gro deleted the moveSignatureTestsToComponentTests branch November 16, 2022 09:56
@T-Gro T-Gro linked an issue Dec 1, 2022 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

Move the signature tests from cambridge suite to CompilerComent tests

3 participants