Skip to content

Conversation

@jnyrup
Copy link
Member

@jnyrup jnyrup commented Aug 9, 2020

When creating a custom assertions class, deriving from ObjectAssertions<TSubject, TAssertions> instead of ReferenceTypeAssertions<TSubject, TAssertions> gives you [Not]Be and [Not]BeEquivalentTo for free.

@jnyrup jnyrup force-pushed the genericObjectAssertions branch from 46f97c9 to 8558be9 Compare August 9, 2020 16:24
@jnyrup
Copy link
Member Author

jnyrup commented Aug 9, 2020

@lg2de Can you think of why When_task_is_checking_synchronization_context_on_UI_thread_it_should_succeed would fail?

@lg2de
Copy link
Contributor

lg2de commented Aug 9, 2020

I'm currently away from office, so I have no chance for detailed analysis.

I've no explanation. There is no logical reason according to these changes.
So, I fear the problem can occur any time.

Maybe we should increase the timeouts. If it is a deadlock, the test will fail anyway. But we must ensure that the problem is not caused by accidental overload of the build machine.

@jnyrup
Copy link
Member Author

jnyrup commented Aug 9, 2020

Ahh... It probably just needs to use a FakeClock.

@jnyrup
Copy link
Member Author

jnyrup commented Aug 10, 2020

I've rerun the CI-build successfully and tracked the flaky test in #1372 1372

@jnyrup jnyrup merged commit 0b32279 into fluentassertions:develop Aug 10, 2020
@jnyrup jnyrup deleted the genericObjectAssertions branch August 10, 2020 06:24
@jnyrup jnyrup restored the genericObjectAssertions branch October 27, 2020 07:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants