Skip to content

Latest commit

 

History

History
194 lines (109 loc) · 10.1 KB

CONTRIBUTING.md

File metadata and controls

194 lines (109 loc) · 10.1 KB
Raw

Contributing to Reqnroll

Contributing can be a rewarding way to teach, improve existing skills, refine the software you work with and build experience. Contributing to open source can also help you grow and learn more in your career or even change careers!

What do I need to know to help?

We do all of our development on GitHub. If you are not familiar with GitHub or pull requests please check out this guide to get started.

Minumum prerequisites to develop:

  • .NET 8.0 SDK
  • .NET 4.6.2 SDK

In order to run all system tests, you will need to have the following SDKs installed:

  • .NET 4.7.2 SDK
  • .NET 4.8.1 SDK
  • .NET 6.0 SDK
  • .NET 7.0 SDK

and of course C# knowledge if you are looking to contribute by coding.

Types of contributions

You can contribute by working on an existing bug/issue or report a new one, build a new functionality based on ideas reported by Reqnroll community or if do not wish to code you can always contribute to writing documentation.

Ground rules & expectations

Bug reports

If you like to contribute by fixing a bug/issue, please start by checking if the issue has already been reported.

Guidelines for bug reports:

  1. Use the GitHub issue search — look for existing issues.

  2. Check if the issue has been fixed — try to reproduce it using the main branch in the repository.

  3. Isolate and report the problem — ideally create a reduced test case. Fill out the provided template.

We label issues that need help, but may not be of a critical nature or require intensive Reqnroll knowledge, to good first issue. This is a list of easier tasks that anybody who wants to get into Reqnroll development can try.

Feature requests

Feature requests are welcome. But please take a moment to find out whether your idea fits with the scope and aims of the project. It's up to you to make a strong case to convince the community of the merits of this feature. Please visit the "ideas" section of the discussion borad to check out the existing requests and vote on the ones already proposed by the community. Since much of the work is done by volunteers, someone who believes in the idea will have to write the code. Please provide as much detail and context as possible.

New Features

If you decide to implement one of the existing feature requests or have one of your own, please create a topic in the "ideas" section of the discussion borad before to discuss what and how you are implementing the new feature. There is a possibility that we might not approve your changes, therefore, it is in the interest of both parties to find this out as early as possible to avoid wasting time.

Naming Conventions and Reserved ID - NuGet Packages

Microsoft has introduced package identity verification for packages on nuget.org. This will allow developers to reserve particular ID prefixes used for identification. This in turn should help users identify which packages have been submitted by the owner of the ID prefix.

We have reserved the Reqnroll NuGet package prefix, which is used to identify official Reqnroll packages. This will mean that new packages with the Reqnroll prefix can only be submitted by Reqnroll, and will indicate that these packages are official.

Please contact us if you would like to submit a package with the Reqnroll prefix.

How to contribute

As mentioned before, we do all of our development on GitHub. If you are not familiar with GitHub or pull requests please check out this guide to get started. All required information about building and testing Reqnroll can be found below.

Please adhere to the coding conventions in the project (indentation, accurate comments, etc.) and don't forget to add your own tests and documentation. When working with Git, we recommend the following process.

Pull requests

in order to craft an excellent pull request:

  1. Fork the project, clone your fork, and configure the remotes.

  2. Configure your local setup. Information to do this can be found below.

  3. If you cloned a while ago, get the latest changes from upstream.

  4. Create a new topic branch (off of main) to contain your feature, change, or fix.

    IMPORTANT: Making changes in main is discouraged. You should always keep your local main in sync with upstream main and make your changes in topic branches.

  5. Commit your changes in logical chunks. Keep your commit messages organized, with a short description in the first line and more detailed information on the following lines. Feel free to use Git's interactive rebase feature to tidy up your commits before making them public.

  6. Newly added tests should pass and be green, same applies to unit tests:

    unittests

  7. Push your topic branch up to your fork.

  8. Open a Pull Request with a clear title and description.

  9. If you haven't updated your pull request for a while, you should consider rebasing on main and resolving any conflicts.

Some important notes to keep in mind:

  • Never ever merge upstream main into your branches. You should always git rebase on main to bring your changes up to date when necessary.
  • Do not send code style changes as pull requests like changing the indentation of some particular code snippet or how a function is called. Those will not be accepted as they pollute the repository history with non functional changes and are often based on personal preferences.
  • By submitting a patch, you agree that your work will be licensed under the license used by the project.
  • If you have any large pull request in mind (e.g. Implementing features, refactoring code, etc), please ask first otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.

Building sources

Visual Studio:

  • Open <Reqnroll.sln> with Visual Studio
  • Build\Build Solution

CLI:

  • Execute dotnet build in a shell

Running tests

Running tests should be possible by running them from Visual Studio or by executing dotnet test in a shell. Some tests in the Reqnroll.SystemTests might be ignored if you do not have all the recommended SDKs installed (see above).

We have three type of tests:

Requirements tests using BDD

There tests should contain illustrative scenarios that describe the behavior of the system. They are not suitable to provide full coverage for all cases (use unit tests for that).

Currently we have the following projects in this category:

  • Reqnroll.Specs - BDD tests for Reqnroll, currently under review and restructuring. Please ask for guidance before working on this project.
  • Reqnroll.ExternalData.ReqnrollPlugin.IntegrationTest
  • Reqnroll.Verify.ReqnrollPlugin.IntegrationTest

Unit tests

These tests are executed in isolation and should provide full coverage for all cases. They are fast to run and should be used to test the behavior of the system in detail.

Currently we have the following projects in this category:

  • Reqnroll.RuntimeTests
  • Reqnroll.GeneratorTests
  • Reqnroll.PluginTests

System (end-to-end) tests

The purpose of these tests is to verify the behavior of the system as a whole. They are slower to run and should be used to test the behavior of the system in a real-world scenario.

These tests are executed end-to-end, i.e. they create sample projects and solutions, install the interim versions of Reqnroll to these projects and configure them for the particular behavior specified by the scenarios. Because of this, the execution of a single test takes approx. 10 seconds.

To optimize the execution certain settings of these tests (e.g. the temporary folder to be used) can be configured using environment variables. You can find a list of these variables in the ConfigurationDriver class. E.g. to override the temporary folder you can set the REQNROLL_TEST_TEMPFOLDER environment variable.

Currently we have the following projects in this category:

  • Reqnroll.SystemTests
  • Reqnroll.TestProjectGenerator.Tests

Building documentation

If you do not wish to contribute by coding you can help us in documentation.

To build local documentation:

  • Install Python:

  • Setup Python environment for the project:

    cd .\docs
.\setupenv.ps1

  • Run (PS or CMD) from the working directory

    .\make.cmd html
    • Result: html pages are generated in the working directory
      • _build/html/index.html

  • For editing the documentation it is recommended to use the "autobuild" option of Sphinx, that monitorse the changed files and rebuilds the documentation automatically:

    .\autobuild.cmd

Where can I go for help?

Please ask in our Contributor Q&A discussion group.

There is also our Discord server.

Thank you for your contributions!