machine / machine.specifications

Machine.Specifications is a Context/Specification framework for .NET that removes language noise and simplifies tests.
MIT License
885 stars 178 forks source link

Feature/async support #384

Closed christophano closed 5 years ago

christophano commented 5 years ago

This should resolve #293, although I'd appreciate design feedback with regards to the naming of the new delegates.

These changes apply to .net framework 4.0+ only.

This change introduces new delegates for Establish, Because, It, and Cleanup that expect a Task return type instead of a void return type, allowing an async lambda to be assigned to each. It also changes the way the delegates are invoked so that the Task, if present, can be awaited.

I have added unit tests to test the async delegates, and included tests for the It delegates in the existing context test. I've also added a test for behaviours with ItAsync delegates, but the ShouldRunSpecification test fails, although it also fails in a synchronous context, so it's not something I've introduced, I'm possibly just misunderstanding the context of these unit tests.

robertcoltheart commented 5 years ago

Thanks for this, I'll take a look. Just FYI that I'm putting together a roadmap for MSpec 2.0, and that the codebase is going to change massively in the near future. To me, this feels very much like a 2.0 feature. Just want to set your expectations.

Without looking I suspect there are subtle ways we need to tweak this, as contexts are created once per class for all It specs etc. Also not wild about having all-new delegates, though I understand why it needs to be like that.

christophano commented 5 years ago

I wasn't a fan of having to create new delegates either, although it was a very simple process , which was a pleasant surprise. I see your point about your focus being on version 2.0. Hopefully that can include async support without needing additional delegates.

robertcoltheart commented 5 years ago

I've done a little bit of research and I think there's a better way of doing this, similar to the way that xUnit is able to run async void methods using the SynchronizationContext. That way we won't need new delegates.

robertcoltheart commented 5 years ago

Closing this, there's a better way of doing it. Tracked here: #293