Quantcast
Channel: Fluent Assertions
Viewing all 1402 articles
Browse latest View live

Source code checked in, #81016

$
0
0
The AttributeBasedFormatter now also works in Silverlight and WP7. WinRT doesn't support enumerating assemblies, so we can't support this feature there.

Commented Feature: Allow for custom IValueFormatters [12364]

$
0
0
I have some cases where I override ToString on my class under test but I'd prefer to use the DefaultValueFormatter as it display nicer formatted results for me (though there are a few properties I would like to omit). There a number ways to fix this but in the end I think allowing the user to setup their own IValueFormatter(s) would be great.
Comments: Associated with changeset 81016: The AttributeBasedFormatter now also works in Silverlight and WP7. WinRT doesn't support enumerating assemblies, so we can't support this feature there.

Commented Feature: Allow for custom IValueFormatters [12364]

$
0
0
I have some cases where I override ToString on my class under test but I'd prefer to use the DefaultValueFormatter as it display nicer formatted results for me (though there are a few properties I would like to omit). There a number ways to fix this but in the end I think allowing the user to setup their own IValueFormatter(s) would be great.
Comments: .NET, WP7 and SL now will automatically find static methods annotated with the [ValueFormatter] attribute. WinRT doesn't support enumerating the assemblies in the AppDomain. However, the Formatter.Formatters collection is now public so you can add your own implementations as well.

Created Issue: Add BeNull() for nullable types [12440]

$
0
0
I just added an assertion for a int? field. I expected a Should().BeNull() extension method but it is not there. Writing actual.SomeValue.Should().Be(null); seems wrong compared to all the other nice extension methods.

Closed Issue: Properties().EqualTo(otherObject) works wrong if called on AndConstraint [12427]

$
0
0
Apparently this test should fail but it succeeds!

  [TestMethod]
  public void Other_should_have_same_props()
  {
    var first = new
      {
        Id = 1,
        Name = "Bogus",
        Title = "Jr"
      };
    first.Should().NotBeNull()
      .And.ShouldHave().SharedProperties().EqualTo(new
        {
          Id = 2,
          Title = "Sr"
        });
  }


If I strip the first assertion, the test fails as I expect:

first.ShouldHave().SharedProperties().EqualTo(new
        {
            Id = 2,
            Title = "Sr"
        });

_Expected property Id to be 2, but found 1._

Is it an expected behavior or bug?

Thanks
Comments: Unfortunately this is the effect of chaining two unrelated assertions. The object.Should().NotBeNull() will return an object of type ObjectAssertions. Since you're chaining this with the property assertions syntax, you are essentially comparing the properties of an ObjectAssertions class. I wouldn't know how to fix this.

Source code checked in, #81026

$
0
0
Updated NuGet package to nuget 2.0

Source code checked in, #81039

$
0
0
Fixed bug in AttributeBasedFormatter

Commented Feature: Exclude properties on nested objects [11841]

$
0
0
We'd like to compare two aggregate roots ignoring a few audit properties (CreatedBy, CreatedOn) on all entities within the root.

AllPropertiesBut() only excludes properties on the root object.

I think this is similar to this post below in that we'd like to configure how nested objects are compared:

http://fluentassertions.codeplex.com/discussions/284312
Comments: Associated with changeset 81039: Fixed bug in AttributeBasedFormatter

New Post: Why so many negation methods?

$
0
0

Hello,

Don't you think that one negation property is a lot better than many negation methods? I wonder what was the decision or reason behind it?

by negation I refer to all these NotX methods.

Keep up the good work! :)

 

Source code checked in, #81041

$
0
0
Added support for using nested property expression with collection indexes during structural equality checks. Fixed a strong-naming issue in the WinRT assembly.

Source code checked in, #81043

$
0
0
Fixed the nuget spec file so that the WinRT stuff is included properly.

Created Issue: Add NotStartWith and NotEndWith methods [12441]

$
0
0
Hello,

There is EndWith and StartWith but not their negating version why?

Source code checked in, #81051

$
0
0
Fix an unnecessary inclusion of some .NET assemblies in the NuGet package

Commented Issue: Add NotStartWith and NotEndWith methods [12441]

$
0
0
Hello,

There is EndWith and StartWith but not their negating version why?
Comments: ** Comment from web user: dennisdoomen **

Because nobody asked for it, yet? ;-)

Commented Issue: Add NotStartWith and NotEndWith methods [12441]

$
0
0
Hello,

There is EndWith and StartWith but not their negating version why?
Comments: ** Comment from web user: EyalShilony **

Haha... okay then! :p


New Post: Using FA for production (as opposite to unit test) code.

$
0
0

I'm looking for better assertions framework than built-in Debug.Assert and consider using FA for that purpose. It should be rather easy to disable it for Release build, but I would rather let it run in Release as well. The biggest problem is FA producing ambiguous exception messages in absence of PDB files - not only the source line numbers are missing, but the actual assertion expression is missing too, so all we get is, for example, in method Foo something which should not be null is null. If we have more than one assertion in that method - no way to tell which one failed.

I understand that it is not primary usage scenario for FA, but still hope to get a good advice how to tailor it to our needs or what other assertion library may suite our needs better.

 

Thank you!

Konstantin

 

Created Issue: HaveElement doesn't seem to work [12446]

$
0
0
I have a class the produces the following XML...

<Operation Name="Test" Duration="0" />

If I parse the above XML into an XDocument and try to assert like so...

var testDoc = XDocument.Parse(result);
testDoc.Should().HaveElement("Operation");

I get the following error...

Expected XML document <Operation Name=\"Test\" Duration=\"1\" /> to have root element with child <Operation>, but no such child element was found.

If I try parsing it as an XElement like so...

var testElement = XElement.Parse(result);
testElement.Should().HaveElement("Operation");

I get the same error of...

Expected XML element <Operation Name=\"Test\" Duration=\"0\" /> to have child element <Operation>, but no such child element was found.

Commented Issue: HaveElement doesn't seem to work [12446]

$
0
0
I have a class the produces the following XML...

<Operation Name="Test" Duration="0" />

If I parse the above XML into an XDocument and try to assert like so...

var testDoc = XDocument.Parse(result);
testDoc.Should().HaveElement("Operation");

I get the following error...

Expected XML document <Operation Name=\"Test\" Duration=\"1\" /> to have root element with child <Operation>, but no such child element was found.

If I try parsing it as an XElement like so...

var testElement = XElement.Parse(result);
testElement.Should().HaveElement("Operation");

I get the same error of...

Expected XML element <Operation Name=\"Test\" Duration=\"0\" /> to have child element <Operation>, but no such child element was found.
Comments: ** Comment from web user: Oliwa **

I found the fix. Use HaveRoot on the XDocument like so...

var testDoc = XDocument.Parse(result);
testDoc.Should().HaveRoot("Operation");

Source code checked in, #81142

$
0
0
Removed some obsolete code from the WP7 version. Added a temporary WP7 app to analyze the loading issues in the unit test runner.

Source code checked in, #81156

$
0
0
Removed the new structural equality assertions from the WP7 version of FA
Viewing all 1402 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>