-
Notifications
You must be signed in to change notification settings - Fork 1.5k
[Tests] Upgrade to xUnit v3 #2907
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
Conversation
Upgrading xunit to v3 to see if this helps our stability issues any.
@mgravell FYI: Seeing if I can get this more stable - found we were spending a lot of time in dispose due to waiting on the quits, but also figured xunit v3 was much easier to profile and such. |
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.
Looking good to me
Hey @NickCraver - what's the status of this one? I just don't want to get into massive merge hell. Anything I can do to help? |
@mgravell Just running a few suites but I think this makes life better but doesn't solve the stability issues from CI (appears to be net neutral there). It makes profiling way easier though - if you're good here 👍 |
Actually - tweaking a few things based on more findings - don't sweat this, I'll eat the merge in. |
Screenshotting this for when you book a flight to convey your regrets mano-a-mano. |
@mgravell Okay realized a big case: shared connection fixture was inadvertently connecting all tests to cluster if any cluster on a
|
Also noticed that The script tests are another category where we're doing script and flush but the problem is the script itself is concurrently run between framework and races...could switch based on target framework/platform dynamically or something and 2 sets of scripts (1 per test suite target framework) would be enough...stupid, but effective. Will keep tweaking. |
Maybe the cancellation tests could use a decorator with fake latency / manual activation. Let me take that. |
@mgravell Overall thinking of making a hostile test suite that runs separately and not parallel (with its own container/servers), but that doesn't need to happen in this PR - just aiming at equal or better. Note that xUnit v3 has an explicit test operator we can use but I think a separate assembly may be the way to go - VS kicks all off at once with shared servers is the rub to figure out. On this I just need to at least fix AppVeyor (broken by this PR) - given how weak those servers are I'm thinking we just run Thoughts? |
@mgravell I suggest pulling this and see what you think locally. There's an annoying bug where clicking from test explorer doesn't go to the method - will file against xUnit but let me know if that's a blocker to merging here, you'd see it more than me coming up. Overall, this should take you from 2min+ down to ~30sec locally and it reproduces some races we've been hunting after getting things much more parallel. I think if you select both suites and run until failure, you'll find some things I can yet fix and some very interesting races...like returning the wrong key, from another test: It's not perfect yet but close on test stability and I can rev, but if it's easier to merge now and continue that, let's go that way and I'll do a follow-up. Definitely more on the table here. |
Looking great locally; a few Mono-related breaks when running as netfx, but I don't think I am going to obsess about that - even less so than netfx. |
(to be clear: those Mono breaks are not related to this PR, which runs very fast) |
@mgravell I've seen this many times now - take a look at: https://github.com/StackExchange/StackExchange.Redis/pull/2907/checks?check_run_id=46350879681
Note the |
@mgravell I think this is a good pause point, will hands-off. Merge at will if you're good and I'll keep an eye on failures and help chase remaining, I think we're far net better as-is. |
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.
Amazing stuff, thanks
Upgrading xUnit to v3 to see if this helps our stability issues any. This runs as an executable making profiling much easier as well, so lends itself better to investigating bottlenecks.