[931] Tests in partial classes cause keypress-by-keypress exceptions

Hello Jeremy,

I don't have Gallio installed, but it sounds like it is problem of that plugin.
When exploring current file in order to put icons on gutter, it seems Gallio
provides all tests in the fixture, while it should provide only tests in
the current file.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


IR> Since the R# JIRA submission process is returning an error at the
IR> moment, I'll report this via the forums:
IR>
IR> After creating some new partial class files to accompany an existing
IR> class file, this exception is now appearing upon making each and
IR> every edit to the file (keypress by keypress) and when changing the
IR> between open files in the IDE:
IR>
IR> JetBrains.Util.LoggerException: Condition (location.First ==
IR> myFile.GetProjectFile()) is false
IR>
IR> at JetBrains.Util.Logger.Assert(Boolean, String) in
IR> c:\Agent\work\3f4db6fd459dabcd\Platform\src\Util\src\Logger\Logger.c
IR> s:line 156 column 5
IR> at
IR> JetBrains.ReSharper.UnitTestExplorer.UnitTestDaemonProcess.Execute()
IR> in
IR> c:\Agent\work\3f4db6fd459dabcd\src\UnitTestExplorer\src\Highlighting
IR> \UnitTestDaemonProcess.cs:line 32 column 11
IR> at
IR> JetBrains.ReSharper.Daemon.Impl.DaemonProcessBase.DoHighlighting(Dae
IR> monProcessKind) in
IR> c:\Agent\work\3f4db6fd459dabcd\src\Daemon\src\Impl\DaemonProcessBase
IR> .cs:line 321 column 19
IR> at
IR> JetBrains.ReSharper.Daemon.Impl.VisibleDocumentDaemonProcess.DoHighl
IR> ighting(Boolean) in
IR> c:\Agent\work\3f4db6fd459dabcd\src\Daemon\src\Impl\VisibleDocumentDa
IR> emonProcess.cs:line 188 column 9
IR> at
IR> JetBrains.ReSharper.Daemon.Impl.c__DisplayClass1. ingJob>b__0() in IR> c:\Agent\work\3f4db6fd459dabcd\src\Daemon\src\Impl\VisibleDocumentDa IR> emonProcess.cs:line 174 column 60 IR> at JetBrains.ReSharper.Daemon.Impl.DaemonThread.ThreadProc() in IR> c:\Agent\work\3f4db6fd459dabcd\src\Daemon\src\Impl\DaemonThread.cs:l IR> ine 127 column 13 IR> at System.Threading.ThreadHelper.ThreadStart_Context(Object) IR> at System.Threading.ExecutionContext.Run(ExecutionContext, IR> ContextCallback, Object) IR> at System.Threading.ThreadHelper.ThreadStart() IR> at JetBrains.Util.Logger.Fail(String messageText) in IR> c:\Agent\work\3f4db6fd459dabcd\Platform\src\Util\src\Logger\Logger.c IR> s:line 264 IR> IR> The solution is building and all tests are running properly (using IR> the Gallio unit testing provider, if that is of any help or IR> relation. IR>]]>

Thanks Ilya, I'll pass that along to the Gallio folks.

Do bear in mind though, that the errors started flying even when the new partial class file was entirely empty.

Oh, and one other note in case it change anything. I mis-stated something slightly in my original post: the tests aren't in the partial class, the tests are in classes that are nested in the partial class. Just in case that might make any difference to the diagnosis. ;)

Hello Jeremy,

I will check the other case two, thanks for clarifying.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


IR> Thanks Ilya, I'll pass that along to the Gallio folks.
IR>
IR> Do bear in mind though, that the errors started flying even when the
IR> new partial class file was entirely empty.
IR>
IR> Oh, and one other note in case it change anything. I mis-stated
IR> something slightly in my original post: the tests aren't in the
IR> partial class, the tests are in classes that are nested in the
IR> partial class. Just in case that might make any difference to the
IR> diagnosis. ;)
IR>

Hello Jeremy,

Nested types work too for built-in NUnit support. Looks like problem in Gallio.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


IR> Hello Jeremy,
IR>
IR> I will check the other case two, thanks for clarifying.
IR>
IR> Sincerely,
IR> Ilya Ryzhenkov
IR> JetBrains, Inc
IR> http://www.jetbrains.com
IR> "Develop with pleasure!"
IR>> Thanks Ilya, I'll pass that along to the Gallio folks.
IR>>
IR>> Do bear in mind though, that the errors started flying even when
IR>> the new partial class file was entirely empty.
IR>>
IR>> Oh, and one other note in case it change anything. I mis-stated
IR>> something slightly in my original post: the tests aren't in the
IR>> partial class, the tests are in classes that are nested in the
IR>> partial class. Just in case that might make any difference to the
IR>> diagnosis. ;)
IR>>

Awesome. Thanks for the quick feedback. I'll pass that info onto the Gallio guys when I get back in to the office tomorrow.

On second thought, if these exceptions are due to Gallio, why is build 923 (for example, I could try others if it would be helpful to your diagnosis) not affected? Only 931 seems to spew constant exceptions once tests are in nested classes.

I suspect this is the 'unstable API' issue we were talking about a couple of weeks ago in a thread I started called something like 'Resharper Ecosystem'

The 'API' which the add-in writers (poor souls) code against potentially changes on every nightly build. It seems it's not really worth plug-in writers making plug-ins work on EAP nightlies. Be interesting to hear what the Gallio people have to say though.

If there were an API issue, I'd expect more problems than I'm seeing. The tests are still catalogued, and can still be run through all of the expected ways, for example. Who knows where the real problem lies. That said, when most R# daily builds work just fine, 931 breaks it, and Gallio hasn't changed the entire time, you can take a guess which of the two tools I suspect is the more likely candidate. ;)

Hello Jeremy,

Build 931 changes didn't have anything to do with unit testing (just verified),
but there is another thing that could change at that time. Like your code ;)
Can it be the case, that you created test in nested type around that time,
or made something else that exposed the bug in ReSharper or Gallio? Could
you please create a small repro project where you get exception, so I can
try it here and see where the problem is. Thanks.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


IR> If there were an API issue, I'd expect more problems than I'm
IR> seeing. The tests are still catalogued, and can still be run through
IR> all of the expected ways, for example. Who knows where the real
IR> problem lies. That said, when most R# daily builds work just fine,
IR> 931 breaks it, and Gallio hasn't changed the entire time, you can
IR> take a guess which of the two tools I suspect is the more likely
IR> candidate. ;)
IR>

This is actually a bug in Gallio. From the sound of it, I made an incorrect assumption about how ExploreFile API should work. I failed to handle the case where a file contained part of a partial class, so when we return tests we should filter them by file. Ahh well.

(This is trickier than it sounds because there are multiple partial class declaration elements so now we have to be careful to return the one that actually belongs to the file we were asked to explore.)

Anyways the fix will be in the next released version of Gallio to be released within a week or two along with a bunch of other improvements.

As for tracking EAPs, it made sense for us to track some of the R# v4.0 EAPs because it was brand new but not so much for v4.1 EAPs. The Gallio plugin interacts with a significant fraction of the R# API (the unit test explorer is the smallest part really). It also contains a few critical deep reflection workarounds for issues where the API itself is deficient. So it takes a fair amount of regression testing involved to verify each release satisfactorily - including a little manual inspection.

In any case, rest assured that I'll add some partial classes to the regression testing suite so hopefully we won't see this one again. :)

Cheers,
Jeff.

Hello,

It also contains a
few critical deep reflection workarounds for issues where the API
itself is deficient.

I'm probably not up-to-date on the issue, but is there a list of such R#
APIs? That I have not heard of such means that either those APIs don't fall
in my domain, or that the issue has not been considered at all yet.

—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”

I've discussed them with Ilya at various times.

There were several problems working with attributes and other metadata in the Psi in R# v3.1. Many of these have been resolved.

A couple remaining issues off the top of my head:

1. Cannot obtain attributes on method return types in Psi. Likewise, method return types are not represented by Psi declared elements which is a little problematic.

2. In order to interact well with the ExploreAssembly API, we need to be able to get the IMetadataLoader. We also benefit from being able to grab the IMetadataAssembly of an IMetadataTypeInfo.

3. We sometimes get unresolved method and type objects back as referenced from custom attributes. We need to detect these cases and resolve the types ourselves using other API.

4. The only constructor on TaskException takes an Exception as input. We don't have an Exception but we do have the exception type name, message and stack trace which is all that a TaskException stores anyways.

5. Test providers do not have enough control over the UTE's presentation. For example, exceptions cannot appear interspersed with other content. Also dynamically generated tests cannot really be supported nicely. Ilya and I have discussed making improvements here such as enabling test providers to control the production of HTML for the UTE test results.

6. There's a bug parsing out attributes with typed array parameters in the metadata API. R# improperly raises an assertion error because it doesn't handle the case.