Instead of going through both of the main testing files (I.E. "ConsoleTests.fs" and "LibraryTests.fs"), I will provide an overview of how they work. If you want to make your way through the source code you can do so by using the following links;
Instead of going through both of the main testing files
(I.E. "ConsoleTests.fs" and "LibraryTests.fs"), I will provide an
overview of how they work. If you want to make your way through the
source code you can do so by using the following links;
The general structure for each file is the same. Each one has a module called `PropertyTests` with "helper" functions at the top of them. It is worth pointing out both of these modules live in name-spaces. This is what allows both "testing" files to use the same module name. If you are wondering why I did it this way, it is because it makes it easier to read the Test Explorer (in Visual Studio).
The general structure for these files are the same. Each one has three
modules called `TestingHelpers`, `PropertyTests` and `UnitTests`. It
is worth pointing out every one of these modules live in
name-spaces. This is what allows both "testing" files to use the same
module names. If you are wondering why I did it this way, it is because
it makes it easier to read the Test Explorer (in Visual Studio).
As an aside, I have kept the "helper" functions next to the actual tests for a reason: to avoid "over-engineering". It seemed a little excessive to "modularise" everything with such a small amount of tests. Although, I admit this approach will need to change if the repository grows in the future. If/when that time comes, TestCentre will need refactoring. Keep this in mind if you decide to add your own changes/features.
As an aside, I have kept the "helper" functions next to the actual
tests for a reason: to avoid "over-engineering". It seemed a little
excessive to "modularise" everything with such a small amount of
tests. Although, I admit this approach will need to change if the
repository grows in the future. If/when that time comes, TestCentre
will need refactoring. Keep this in mind if you decide to add your own
One way to denote a property test from a unit test is by looking at their attributes. If a test has `[<Property>]` next to it, it is a property test. If a test has `[<Fact>]` next to it, it is a unit test. For example,
One way to denote a property test from a unit test is by looking at
their attributes. If a test has `[<Property>]` next to it, it is a
property test. If a test has `[<Fact>]` next to it, it is a unit
test. For example,
```f#
// This is a unit test -- uses xUnit.
@ -33,10 +52,21 @@ let ``Can create an image with a full overlay`` () =
As stated in other parts of this wiki, make sure you have a folder called "SavingTestArea" within TestCentre. If you do not have this folder on your machine, a lot of the tests will fail. This is because TestCentre uses it as a place to save and check the images it creates. To help you check, here is what your TestCentre project should look like:
As stated in other parts of this wiki, make sure you have a folder
called "SavingTestArea" within TestCentre. If you do not have this
folder on your machine, a lot of the tests will fail. This is because
TestCentre uses it as a place to save and check the images it
creates. To help you check, here is what your TestCentre project
The easiest way to add this folder to TestCentre is by right-clicking on "TestCentre" in Visual Studio's Solution Explorer. From there, head to *Add -> New Folder*. Having said that, you can add the "SavingTestArea" folder to TestCentre with File Explorer if you want. This is because Visual Studio does not need to know it exists. You just need it on your machine.
The easiest way to add this folder to TestCentre is by right-clicking
on "TestCentre" in Visual Studio's Solution Explorer. From there, head
to *Add -> New Folder*. Having said that, you can add the
"SavingTestArea" folder to TestCentre with File Explorer if you
want. This is because Visual Studio does not need to know it
exists. You just need it on your machine.
