https://github.com/rsvilenov/fluentassertions.properties
Unofficial FluentAssertions extensions for testing the behavior of class/struct/record properties.
https://github.com/rsvilenov/fluentassertions.properties
assertions c-sharp fluent-assertions unit-testing xunit
Last synced: 16 days ago
JSON representation
Unofficial FluentAssertions extensions for testing the behavior of class/struct/record properties.
- Host: GitHub
- URL: https://github.com/rsvilenov/fluentassertions.properties
- Owner: rsvilenov
- License: apache-2.0
- Created: 2021-08-02T22:33:28.000Z (over 3 years ago)
- Default Branch: master
- Last Pushed: 2024-07-19T15:27:16.000Z (9 months ago)
- Last Synced: 2025-03-18T17:37:03.840Z (about 1 month ago)
- Topics: assertions, c-sharp, fluent-assertions, unit-testing, xunit
- Language: C#
- Homepage:
- Size: 208 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# FluentAssertions.Properties
Unofficial FluentAssertions extensions for testing the behavior of class/struct/record properties.
[](https://github.com/rsvilenov/FluentAssertions.Properties/actions/workflows/build.yml)
[](https://coveralls.io/github/rsvilenov/FluentAssertions.Properties)
[](https://opensource.org/licenses/Apache-2.0)
[](https://www.nuget.org/packages/FluentAssertions.Properties)
## Table of Contents
- [How?](#How)
- [Why?](#Why)
- [Installation](#Installation)
- [Documentation](#Documentation)
## How?
Some common scenarios:
* Testing that all properties in a class provide symmetric access, i.e. they return the same value that has been assigned to them
```csharp
var instanceUnderTest = new SampleDto();
var testValues = new Fixture().Create();
instanceUnderTest
.Properties()
.ThatAreWritable
.WhenCalledWithValuesFrom(testValues)
.Should()
.ProvideSymmetricAccess();
```
Speaking in the lingo of AutoFixture, we can say that `ProvideSymmetricAccess()` verifies that the properteis are "well-behaved writables" (see [AutoFixture's WritablePropertyAssertion idiom](http://www.shujaat.net/2013/05/writable-property-assertions-using.html)).
* Testing that getters/setters throw exceptions in certain cases
```csharp
var instanceUnderTest = new TestClass();
instanceUnderTest
.Properties()
.ExactlyOfType()
.WhenCalledWith(string.Empty)
.Should()
.ThrowFromSetter()
.WithMessage("Empty strings are not accepted.");
```
* Selecting specific properties to test by their type and value
```csharp
var instanceUnderTest = new TestClass();
instanceUnderTest
.Properties()
.ExactlyOfType()
.HavingValue("some value")
.Should()
.HaveCount(2);
```
or selecting individual properties by name
```csharp
var instanceUnderTest = new TestRecord();
string testValue = Guid.NewGuid().ToString();
instanceUnderTest
.Properties(o => o.StringPropertyOne, o => o.StringPropertyTwo)
.WhenCalledWith(testValue)
.Should()
.ProvideSymmetricAccess();
```
A more comprehensive explanation of the selection and assertions methods, provided by this library, can be found [here](./Selectors.md) and [here](./Assertions.md).
## Why?
> Even if code is trivial you should still test it.
>
> -- Mark Seemann
### Why should I consider testing my class properties?
From the perspective of the caller, the public properties are part of the public "interface" of a type. They imply a contract - their semantics is such that
one expects them to behave like public fields. However, they have accessor methods,
which can contain logic that modifies the expected behavior. Implementing nontrivial logic in the accessors is sometimes considered
to be an [anti-pattern](https://www.codeproject.com/Tips/1069467/Asymmetric-Property-anti-pattern),
and rightfully so - in order for a programmer to see how a particular property behaves,
they have to open the implementation of the type and look inside the code. The presence of accessor
methods is a big part of the reason why Microsoft has provided a list of [bad practices and design guidelines](https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/property), concerning the implementation of properties.
### But testing property accessors goes against the conventional wisdom!
There is a rule of thumb that says properties should not be tested if their getter and setter do not
contain any logic, e.g. if they are [auto-implemented](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/auto-implemented-properties). Robert C. Martin goes as far as to say that [testing property accessors is foolish](https://blog.cleancoder.com/uncle-bob/2013/03/06/ThePragmaticsOfTDD.html), regardless of whether their accessors contain logic or not. However, there are other prominent authors, such as Mark Seeman, who [strongly disagree](https://blog.ploeh.dk/2013/03/08/test-trivial-code/). And there seems to be a [not-so-small minority](https://stackoverflow.com/questions/18967697/should-you-unit-test-simple-properties), which thinks that testing all public properties is absolutely necessary.
## Installation
This library is distributed as a [NuGet](https://www.nuget.org/packages/FluentAssertions.Properties/).
To install `FluentAssertions.Properties`, run the following command in the Package Manager Console:
```
PM> Install-Package FluentAssertions.Properties
```
Or use this command with the .NET CLI:
```
> dotnet add package FluentAssertions.Properties
```
## Documentation
* [Property selector methods](https://github.com/rsvilenov/FluentAssertions.Properties/blob/master/docs/Selectors.md).
* [Assertion methods](https://github.com/rsvilenov/FluentAssertions.Properties/blob/master/docs/Assertions.md).