You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge pull request #1256: Merge milestones/M153 to releases/shipped
- Includes Git 2.22
- Moves placeholder database into SQLite for better performance.
- Fixes when libgit2 repos are acquired and disposed for better performance of checkout (where detected) and other operations that rely heavily on the read-object hook.
- Adds additional logging for folder and file placeholder creation.
- Other bug fixes for reliability
Copy file name to clipboardExpand all lines: AuthoringTests.md
+84-20Lines changed: 84 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,39 +2,103 @@
2
2
3
3
## Functional Tests
4
4
5
-
###1. Running the functional tests
5
+
#### Runnable functional test projects
6
6
7
-
Our functional tests are in the `GVFS.FunctionalTests` project. They are built on NUnit 3, which is available as a set of NuGet packages.
7
+
-`GVFS.FunctionalTests`
8
+
-`GVFS.FunctionalTests.Windows`
8
9
9
-
To run the functional tests:
10
-
1. Open GVFS.sln in Visual Studio
11
-
2. Build all, which will download the NUnit framework and runner
12
-
3. You have three options for how to run the tests, all of which are equivalent.
13
-
1. Run the `GVFS.FunctionalTests` project. Even better, set it as the default project and hit F5.
14
-
2. Use the command line runner. After building, execute `Scripts\RunFunctionalTests.bat`
15
-
3. If you want to use Visual Studio's Test Explorer, you need to install the NUnit 3 Test Adapter in VS | Tools | Extensions and Updates.
10
+
`GVFS.FunctionalTests` is a .NET Core project and contains all cross-platform functional tests. `GVFS.FunctionalTests.Windows`, contains functional tests that require Windows. Additionally, `GVFS.FunctionalTests.Windows` includes all the `GVFS.FunctionalTests` allowing it to run both cross-platform and Windows-specific functional tests.
16
11
17
-
Running the `GVFS.FunctionalTests` project is probably the most convenient for developers. `RunFunctionalTests.bat` will be used on the build machines.
12
+
#### Other functional test projects
13
+
14
+
*GVFS.NativeTests*
15
+
16
+
`GVFS.NativeTests` contains tests written in C++ that use the Windows API directly. These tests are called from the managed tests (see above) using PInvoke.
17
+
18
+
*GVFS.FunctionalTests.LockHolder*
19
+
20
+
The `LockHolder` is a small program that allows the functional tests to request and release the `GVFSLock`. `LockHolder` is useful for simulating different timing/race conditions.
21
+
22
+
## Running the Functional Tests
23
+
24
+
The functional tests are built on NUnit 3, which is available as a set of NuGet packages.
25
+
26
+
### Windows
27
+
28
+
1. Build VFS for Git:
29
+
30
+
**Option 1:** Open GVFS.sln in Visual Studio and build everything.
31
+
32
+
**Option 2:** Run `Scripts\BuildGVFSForWindows.bat` from the command line
33
+
34
+
2. Run the VFS4G installer that was built in step 2. This will ensure that ProjFS is properly installed/enabled on your machine, and that VFS4G will be able to find the correct version of the pre/post-command hooks. The installer will be placed in `BuildOutput\GVFS.Installer.Windows\bin\x64\<Debug or Release>`
35
+
3. Run the tests **with elevation**. Elevation is required because the functional tests create and delete a test service.
36
+
37
+
**Option 1:** Run the `GVFS.FunctionalTests.Windows` project from inside Visual Studio launched as Administrator.
38
+
39
+
**Option 2:** Run `Scripts\RunFunctionalTests.bat` from CMD launched as Administrator.
40
+
41
+
#### Selecting Which Tests are Run
42
+
43
+
By default, the functional tests run a subset of tests as a quick smoke test for developers. There are three mutually exclusive arguments that can be passed to the functional tests to change this behavior:
44
+
45
+
-`--full-suite`: Run all configurations of all functional tests
46
+
-`--extra-only`: Run only those tests marked as "ExtraCoverage" (i.e. the tests that are not run by default)
47
+
-`--windows-only`: Run only the tests marked as being Windows specific
48
+
49
+
**NOTE**`Scripts\RunFunctionalTests.bat` already uses some of these arguments. If you run the tests using `RunFunctionalTests.bat` consider locally modifying the script rather than passing these flags as arguments to the script.
50
+
51
+
### Mac
52
+
53
+
1. Build VFS for Git: `Scripts/Mac/BuildGVFSForMac.sh`
54
+
2. Run the tests: `Scripts/Mac/RunFunctionalTests.sh `
55
+
56
+
If you need the VS for Mac debugger attached for a functional test run:
57
+
58
+
1. Make sure you've built your latest changes
59
+
2. Run `./ProjFS.Mac/Scripts/LoadPrjFSKext.sh`
60
+
3. Open GVFS.sln in VS for Mac
61
+
4. Run->Run With->Custom Configuration...
62
+
5. Select "Start external program" and specify the published functional test binary (e.g. `/Users/<USERNAME>/Repos/VFSForGit/Publish/GVFS.FunctionalTests`)
63
+
6. Specify any desired arguments (e.g. [a specific test](#Running-Specific-Tests) )
64
+
7. Run Action -> "Debug - .Net Core Debugger"
65
+
8. Click "Debug"
66
+
67
+
### Customizing the Functional Test Settings
18
68
19
69
The functional tests take a set of parameters that indicate what paths and URLs to work with. If you want to customize those settings, they
20
70
can be found in [`GVFS.FunctionalTests\Settings.cs`](/GVFS/GVFS.FunctionalTests/Settings.cs).
21
71
22
-
### 2. Running Full Suite of Tests vs. Smoke Tests
23
72
24
-
By default, the VFS for Git functional tests run a subset of tests as a quick smoke test for developers. To run all tests, pass in the `--full-suite` flag.
73
+
## Running Specific Tests
74
+
75
+
Specific tests can be run by adding the `--test=<comma separated list of tests>` command line argument to the functional test project/scripts.
76
+
77
+
Note that the test name must include the class and namespace and that `Debug` or `Release` must be specified when running the functional test scripts.
1. Set `GVFS.FunctionalTests.Windows` as StartUp project
88
+
2. Project Properties->Debug->Start options->Command line arguments (all on a single line): `--test=GVFS.FunctionalTests.Tests.EnlistmentPerFixture.GitFilesTests.CreateFileTest`
25
89
26
-
### 3. Running specific tests
90
+
Mac:
27
91
28
-
Specific tests can be run by specifying `--test=<comma separated list of tests>` as the command line arguments to the functional test project.
Each piece of functionality that we add to VFS for Git should have corresponding functional tests that clone a repo, mount the filesystem, and use existing tools and filesystem
33
97
APIs to interact with the virtual repo.
34
98
35
99
Since these are functional tests that can potentially modify the state of files on disk, you need to be careful to make sure each test can run in a clean
36
100
environment. There are three base classes that you can derive from when writing your tests. It's also important to put your new class into the same namespace
37
-
as the base class, because NUnit treats namespaces like test suites, and we have logic that keys off of that for deciding when to create enlistments.
101
+
as the base class, because NUnit treats namespaces like test suites, and we have logic that keys off that for deciding when to create enlistments.
38
102
39
103
1.`TestsWithLongRunningEnlistment`
40
104
@@ -49,11 +113,11 @@ as the base class, because NUnit treats namespaces like test suites, and we have
49
113
50
114
3.`TestsWithEnlistmentPerTestCase`
51
115
52
-
Derive from this class if you need a brand new enlistment per test case. This is the most reliable, but also most expensive option.
116
+
Derive from this class if you need a new enlistment created for each test case. This is the most reliable, but also most expensive option.
53
117
54
-
### 5. Updating the remote test branch
118
+
##Updating the Remote Test Branch
55
119
56
-
By default, `GVFS.FunctionalTests` clones `master`, checks out the branch "FunctionalTests/YYYYMMDD" (with the day the FunctionalTests branch was created),
57
-
and then removes all remote tracking information. This is done to guarantee that remote changes to tip cannot break functional tests. If you need to update
120
+
By default, the functional tests clone `master`, check out the branch "FunctionalTests/YYYYMMDD" (with the day the FunctionalTests branch was created),
121
+
and then remove all remote tracking information. This is done to guarantee that remote changes to tip cannot break functional tests. If you need to update
58
122
the functional tests to use a new FunctionalTests branch, you'll need to create a new "FunctionalTests/YYYYMMDD" branch and update the `Commitish` setting in `Settings.cs` to have this new branch name.
59
123
Once you have verified your scenarios locally you can push the new FunctionalTests branch and then your changes.
0 commit comments