-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proof of concept for event counter tests #23663
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 seal
ed 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public static TestEntityFrameworkEventSource TestEventSource = new(); | |
public static readonly TestEntityFrameworkEventSource TestEventSource = new(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: using declaration syntax
Superseded by #23826 |
@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?