[WIP] Refactor tests tryout

[304NotModified]

This is a tryout to continue the discussion in #70, with some more concrete examples.

These are 2 directions we could go now, to improve the readability of the tests.

What I have done:

• moved the testcase to a folder and made the name shorter
• created a helper to get the filename from a generic (so it's easy to move from test to testcase and visa versa)
• created 2 options we could go to (or a mix of course)
  1. option 1 is a small change compared to the current testcode
  2. option 2 refactors also the helpers and so less duplicate testcode is needed. Also using C#7 tuples makes stuff easier to read

note: this assumes that the class name and the filename are the same. I think that's even best practice.

[304NotModified]

note: this is just a duplicate for demo purpose.

[304NotModified]

Please share your thoughts on this refactor, thanks!

[304NotModified]

Please share your thoughts on this refactor, thanks!

Polite bump @mikkelbu. This would help me writing new code and so fixing #69

[mikkelbu]

Hi @304NotModified

I like the tuples, and I think that we should replace all the old unamed tuples with named tuples throughout the code base (to get rid of Item1...).

Looking at your examples I prefer option 2, but I think that the two examples are only working by mistake (I could be wrong as it is past midnight, and I'm very tired). The reason for why I think that there is a problem is that the class CanAssignToWhenArgumentIsImplicitlyTypedArrayAndNotAssignable should not be compiled (or at least it used not to be compiled, the file was only copied to the output), so we cannot use the name as a type parameter in e.g. await GetAttributeSyntaxAsync<CanAssignToWhenArgumentIsImplicitlyTypedArrayAndNotAssignable>().

The problem is that we have the following change in the csproj

-    <Compile Remove="Targets\Extensions\AttributeArgumentSyntaxExtensionsTestsCanAssignToWhenArgumentIsImplicitlyTypedArrayAndNotAssignable.cs" />
+    <Compile Remove="Targets\Extensions\CanAssignToWhenArgumentIsImplicitlyTypedArrayAndNotAssignable.cs" />

but the location of the file is now - in the folder AttributeArgumentSyntaxExtensionsTests - Targets\Extensions\AttributeArgumentSyntaxExtensionsTests\CanAssignToWhenArgumentIsImplicitlyTypedArrayAndNotAssignable.cs, so we have removed a non-existing file from compilation, and as a result Targets\Extensions\AttributeArgumentSyntaxExtensionsTests\CanAssignToWhenArgumentIsImplicitlyTypedArrayAndNotAssignable.cs will be compiled. I find it a bit strange that msbuild does not complain about Compile Remove of a non-existing file, but I don't know much about this.

I'll try to take a closer look tomorrow, but now I need to get some sleep.

[mikkelbu]

So, I finally had time to look at this again. If we correct the csproj, such that Compile Remove refers to the file, then the compilation fails, since the type CanAssignToWhenArgumentIsImplicitlyTypedArrayAndNotAssignable is unknown.

I still have the feeling that many of the tests using the files in Targets\Extensions\ should be converted into unittests (or perhaps just a couple of tests, each with testcases). If we e.g. compare AttributeArgumentSyntaxExtensionsTestsCanAssignToWhenParameterIsByteAndArgumentIsInt32.cs and AttributeArgumentSyntaxExtensionsTestsCanAssignToWhenParameterIsDoubleAndArgumentIsInt32.cs then the tests are the same up to the name and the files in Targets\Extensions\ are the same except for a type and the name of the class.

Of cause we will need some kind of integration tests to see that the entire flow works, but we don't need these integration tests to tests all the corner-cases of the code. For this I would rather have unittests calling CanAssignTo directly (it can be that we need to restructure the code slightly to make it possible to create these unittest).

For the integration tests I still feel that having the input as part of the test will help when reading and also adding tests.

But it can be that I'm trying change too much in one step.

[304NotModified]

Superseded by #105 :)

[mikkelbu]

Wow. I'm too slow 😄. I had started to write that I would close this due to #105, but got sidetracked by a late night snack, and you beat me to it.