Jonas Nyrup

@leus as we're discussing several methods, which one(s) are you looking for?

> I'd rather use this opportunity to correct the situation. Then I guess we should have: * `HaveAttribute(string expectedName)` * The attribute exists and can have any value * `HaveAttributeWithValue(string...

> I think the last one is a bit ambiguous. I would opt for `NotHaveAttributeValue` and to require the attribute itself actually exist. (Which would make `HaveAttributeValue` the opposite) If...

> > If we let p be "having the attribute" and q "with the given value", then the negation is !(p && q) and by applying [De Morgan's Law](https://en.wikipedia.org/wiki/De_Morgan%27s_laws) we...

I agree with the proposed methods in https://github.com/fluentassertions/fluentassertions/issues/2589#issuecomment-2143408313

> Can I throw in another thought, or is it too late? We always welcome input (until we express otherwise). > In #2321 we changed the behavior to _not_ check...

> In the past, how did you decide what makes a good candidate? Is it simply a matter of what is popular, common or heavily use? A combination of multiple...

>They are two different methods, with potentially two different implementations. So that's why I was suggesting that a `BeParsableInto` method could execute two assertions, one on `Parse` and one on...

To me we must assume that `Parse` and `TryParse` can parse the exact set of strings. The proposal seems not to be about verifying an implementation of `IParsable`, but whether...

> But what does it mean to be _parsable to a GUID_. Does it mean that you can call `IParseable.Parse` or `TryParse`? It doesn't matter, that's an implementation detail to...