Testing

TLDR;
Look into NUnit. Use hand-written scanner/barcode/file-system adapters (Moq and/or FlaUI). Non-UI unit tests can be set to run on GitHub Actions using Windows runners. UI/hardware tests on a self-hosted Windows machine or controlled workstation.

# Background

## Scanning App

Currently the Scanning application has no automated testing. Developers are tasked with testing each change manually and reviewers must do the same. This ticket aims to implement basic testing to ensure the core functionality of the application is not impacted by changes.

The repository as it stands has some factors that may make it hard to implement and maintain useful tests. See some of the factors below:
- does not use a lot of abstraction
- Makes it harder to use mocking features
- file and hardware I/O functionality are coupled such that testing individual pieces may be impossible (restricts automation)
- Implementing Interfaces or libraries for scanner, TWAIN, and Barcode Reader would allow for easier to manage testing
- Logic and UI intertwined
- having code in form files limits proper testing practices

Creating tests is still possible, but the work may take longer without considerable architecture changes.
Considerable architecture changes will take a lot of time and effort.

## Tickets

Ticket #32977 'Scanner - Create Test Project for Automated Tests' lists one method that may be used to handle some of these tests. Please read on and create tickets as needed.

## Testing

The github already has tests for testing the application build.
This writeup will focus on the following types of tests:

Unit Testing
- test the smallest portion or work possible (a unit of work)
- removing all other variables (databases, file I/O, networks, API responses, ect.)
- EX. a single function (multiple unit test may have to be created to cover all possible paths through the function)

Integration Testing
- test the connection between 2 or more components ability to integrate.
- EX. Do the various projects within the solution pass information to each other correctly? Are all cases handled? Is the information passed through completely?
- Some third party (API) testing may be harder to establish

# Sources

https://learn.microsoft.com/en-us/dotnet/core/testing/

# OpenSource Options

## NUnit

GitHub Repo -> https://github.com/nunit/nunit
Mainly for testing UI and "hardware-in-the-loop" tests. Can be used for non UI testing

PROS:

- Support for .NET framework v4.8
- OpenSource
- supports user-created fakes, stubs, adapters, and can mock interfaces
- Can be implemented incrementally
- Works with little abstraction

CONS:

- Might need workarounds for TWAIN

OTHER CONSIDERATIONS

- Has to be run locally (not in GitHub Actions)

## MSTest

GitHub Repo -> https://github.com/microsoft/testfx
Mainly for logic testing (little to no UI testing)

PROS:

- Easy to implement with Visual Studio
- Easy to learn (especially with experience in Microsoft testing)
- Can be used in GitHub Actions

CONS:

- Might be harder to implement with .NET framework v4.8
- Might be more work to maintain

## xUnit.net

GitHub Repo -> https://github.com/xunit/xunit

PROS:

- good documentation and active community

CONS:

- Might not cover TWAIN management
- Might be harder to implement with .NET framework v4.8