Skip to main content

Starting tests

· One min read

For starting tests there is a plethora of frameworks. What we want is to

  1. Make it fast
  2. See the results in a good form

So we start

TITLE: ADR 003 - Tests​

Submitters​

  • Andrei Ignat

Change Log​

Referenced Use Case(s)​

All use cases, e.g.

  • UseCases001 - No Authentication , upload

must be enforced via an automated Test.

Context​

The tests are an important part of the software - so the framework that I am using is important.

Also , the organization of the software must allow testing business rules more than endpoints / GUI that are changing very often.

Also, the code coverage is pretty important - should be at least 80%

Proposed Design​

Every GUI application ( Desktop,Console, WebAPI ) must be skinny - i.e. passing data to a business component.

Also, Business should not call static functions ( e.g. DateTime.Now, Environment.CurrentUser) but pass interfaces or functions in order to be Mocked.

Considerations​

Testing GUI's / endpoints should be make at least possible in the developing of the app, because they are changing fast.

Decision​

As frameworks we will have :

XUnit ( preferable constructor over [SetUp] ) - see https://testsigma.com/blog/nunit-vs-xunit/

FluentAssertion - to improve running and debugging

LightBDD - to display tests in a good form

NSubstitute - instead of Moq - see https://github.com/moq/moq/issues/1374

Rocks - https://github.com/JasonBock/Rocks/

dotCover CLI - https://www.jetbrains.com/help/dotcover/Running_Coverage_Analysis_from_the_Command_LIne.html

Format:

  • ADR002 - Architecture of the application

References​

ADR based on​

https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/locales/en/templates/decision-record-template-by-edgex/index.md