Proof of concept for event counter tests#23663
Conversation
There was a problem hiding this comment.
A different approach:
Make these fields protected and expose them in the (test-) subclass as properties, so that they can be read and reset.
The methods here could then be sealed again (as the class can't be sealed if want to subclass), and singleton can remain static readonly.
|
|
||
| public class EventSourceFixture | ||
| { | ||
| public static TestEntityFrameworkEventSource TestEventSource = new(); |
There was a problem hiding this comment.
| public static TestEntityFrameworkEventSource TestEventSource = new(); | |
| public static readonly TestEntityFrameworkEventSource TestEventSource = new(); |
roji
left a comment
roji
left a comment
There was a problem hiding this comment.
I'm generally not a big fan of changing product code to suit testing needs (and introducing virtual dispatches in runtime).
But if we feel there's enough value in preventing regressions (since we're already fixing the initial implementation bugs that we know of), we can do this.
| public EventSourceTest(EventSourceFixture fixture) | ||
| { | ||
| _fixture = fixture; | ||
| _isTestThread.Value = true; |
There was a problem hiding this comment.
Technically, I'm not sure it's guaranteed that the thread constructing (and disposing) the class it the same one that runs the thread - it may be safer to just call a method inside each test which does this, and returns a disposable to reset back.
|
|
||
| for (var i = 1; i <= 3; i++) | ||
| { | ||
| using (var context = new SomeDbContext()) |
|
Superseded by #23826 |
3 participants
@roji @dotnet/efteam This is testing to make sure we fire event counters when we intend to. (Two tests fail since I didn't fix the bugs in this PR.) To me, this seems like a reasonable compromise in terms of changing the product code in order to be able to test it. What do others think?