Closed weitzhandler closed 2 years ago
Blocker: #41.
We've fixed the build problems and converted the test project into a cross-compiling .NET Core style project. Can you please rebase your changes?
Well now that I can actually build and debug this on my machine, I see that it's much easier to use HaveElementWithValue<T>(string elementKey, T value);
,
Replacing the tests shouldn't be too hard either. I understand I'll need some additional tests, but I want to get your green light before committing any work.
After this PR is done, we'll release the package.
So are you fine with HaveElementWithValue<T>(string elementKey, T value);
instead of an arbitrary string value?
So are you fine with
HaveElementWithValue<T>(string elementKey, T value);
instead of an arbitrary string value?
I think it's weird to have the generic T
for the value since all other APIs (HaveValue
and HaveElement
) take a string.
Which is a valid point, but in fact the HaveElement
itself should have been written this way, and in fact I'd be happy to rewrite it, it would just obviously take longer until I find a nice time spot to take of it.
Can you still provide a string value as an argument to the T
parameter? I guess the underlying JToken.Value<T>()
will support that, right?
I'm sure it will. Will make an overload.
On Thu, Aug 13, 2020, 20:07 Dennis Doomen notifications@github.com wrote:
Can you still provide a string value as an argument to the T parameter? I guess the underlying JToken.Value
() will support that, right? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fluentassertions/fluentassertions.json/pull/40#issuecomment-673597458, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUXFHA7VL3TNUE3EBMWM43SAQMWFANCNFSM4PKFTXYQ .
What happens if I invoke it with a custom type? e.g.
HaveElementWithValue("key", new MyClass());
Closing because of inactivity
Fixes #39