AutoFixture is currently being developed in C# on .NET 4.5.2 and .NET Standard using Visual Studio 2017 Update 5 or later with xUnit.net as the unit testing framework. So far, all development has been done with TDD, so there's a pretty high degree of code coverage, and the aim is to keep it that way.
AutoFixture uses FAKE as a build engine. If you would like to build the AutoFixture locally, run the build.cmd file and wait for the result.
The repository state (the last tag name and number of commits since the last tag) is used to determine the build version. If you would like to override the auto-generated AutoFixture version, set the BUILD_VERSION environment variable before calling the build.cmd file. Example for PowerShell:
$env:BUILD_VERSION='3.52.0'; .\build.cmdRefer to the Build.fsx file to get information about all the supported build keys.
All the external dependencies are restored during the build and don't need to be committed to the repository.
If you would like to work with project offline, ensure to trigger a build while you are still online so dependencies are cached. To trigger a build run the build.cmd file located in the root directory of the repo.
There are several different targeted solutions to be found under the \Src folder, but be aware that the final verification step before pushing to the repository is to successfully run all the unit tests in the build.cmd file.
As part of the verification build, Code Analysis is executed in a configuration that treats warnings as errors. For unit test projects code most of the rules are suppressed so only missing warnings are expected. No CA warnings should be suppressed unless the documented conditions for suppression are satisfied. Otherwise, a documented agreement between at least two active developers of the project should be reached to allow a suppression of a non-suppressible warning.
When developing for AutoFixture, please respect the coding style already present. Look around in the source code to get a feel for it.
Please keep line lengths under 120 characters. Line lengths over 120 characters don't fit into the standard GitHub code listing window, so it requires vertical scrolling to review.
Also, please follow the Open Source Contribution Etiquette. AutoFixture is a fairly typical open source project: if you want to contribute, start by creating a fork and sending a pull request when you have something you wish to commit. When creating pull requests, please keep the Single Responsibility Principle in mind. A pull request that does a single thing very well is more likely to be accepted. See also the article The Rules of the Open Road for more good tips on working with OSS and Pull Requests, as well as these 10 tips for better Pull Requests.
For complex pull requests, you are encouraged to first start a discussion on the issue list. This can save you time, because the AutoFixture regulars can help verify your idea, or point you in the right direction.
Some existing issues are marked with the good first issue tag. These are good candidates to attempt, if you are just getting started with AutoFixture.
When you submit a pull request, you can expect a response within a day or two. We (the maintainers of AutoFixture) have day jobs, so we may not be able to immediately review your pull request, but we do make it a priority. Also keep in mind that we may not be in your time zone.
Most likely, when we review pull requests, we will make suggestions for improvement. This is normal, so don't interpret it as though we don't like your pull request. On the contrary, if we agree on the overall goal of the pull request, we want to work with you to make it a success.
AutoFixture follows Semantic Versioning 2.0.0 for the public releases (published to the nuget.org).
AutoFixture has been set up for Continuous Integration. The build is hosted on AppVeyor and runs automatically every time a new commit is pushed to any of the public branches or a Pull Request is submitted. AutoFixture uses GitHub's Commit Status API to prevent Pull Requests that don't pass the build from being accidentally merged.
The build process is implemented in the Build.fsx file using FAKE and consists of four main steps:
- Compile all projects
- Run static analysis on all projects using FxCop and Roslyn Analyzers package.
- Run all tests
- Create NuGet packages
The NuGet packages produced by the latest build can be downloaded directly from AppVeyor.