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
Copy file name to clipboardExpand all lines: docs/building/unix-instructions.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -48,7 +48,7 @@ On macOS a few components are needed which are not provided by a default develop
48
48
* libomp 7
49
49
* libgdiplus
50
50
* gettext
51
-
* All the requirements necessary to run .NET Core 3.1 applications. To view macOS prerequisites click [here](https://docs.microsoft.com/en-us/dotnet/core/macos-prerequisites?tabs=netcore30).
51
+
* All the requirements necessary to run .NET Core 3.1 applications. To view macOS prerequisites click [here](https://docs.microsoft.com/en-us/dotnet/core/install/macos?tabs=netcore31#dependencies).
52
52
53
53
One way of obtaining CMake and other required libraries is via [Homebrew](https://brew.sh):
Copy file name to clipboardExpand all lines: docs/building/windows-instructions.md
+13-5
Original file line number
Diff line number
Diff line change
@@ -56,21 +56,29 @@ You can use the Developer Command Prompt, Powershell or work in any regular cmd.
56
56
From a (non-admin) Command Prompt window:
57
57
58
58
-`build.cmd` - builds the assemblies
59
-
-`build.cmd -runTests` - called after a normal "build.cmd" will run all tests
60
-
-`build.cmd -buildPackages` called after a normal “build.cmd” will create the NuGet packages with the assemblies in “bin"
59
+
-`build.cmd -test -integrationTest` - builds the assemblies and runs all tests, including integration tests.
60
+
-`build.cmd -pack` builds the assemblies and generates the corresponding NuGet packages with the assemblies in `artifacts\packages`"
61
61
62
62
**Note**: Before working on individual projects or test projects you **must** run `build.cmd` from the root once before beginning that work. It is also a good idea to run `build.cmd` whenever you pull a large set of unknown changes into your branch.
63
63
64
64
## Running Tests
65
65
66
66
### Running tests from Visual Studio
67
67
68
-
After successfully building, run tests in the Visual Studio Test Explorer window.
68
+
After successfully building, run tests through the Visual Studio Test Explorer window.
69
+
70
+
Before running tests on Visual Studio, make sure you have selected the correct processor architecture (`x64`, `x86`) for running unit tests that your machine supports and that you have built ML.NET on. To check, click on the settings image in the Test Explorer window, then on "Process Architecture for AnyCPU Projects", and then on the correct architecture type, as demonstrated in the image below:
71
+
72
+

69
73
70
74
### Running tests from the command line
71
75
72
-
From the root, run `build.cmd` and then `build.cmd -runTests`.
73
-
For more details, or to test an individual project, you can navigate to the test project directory and then use `dotnet test`
76
+
From root, run `build.cmd -test -integrationTest`.
77
+
For more details, or to test an individual project, you can navigate to the test project directory and then use `dotnet test`.
78
+
79
+
## Running Benchmarks
80
+
81
+
For more information on running ML.NET benchmarks, please visit the [benchmarking instructions](../../test/Microsoft.ML.PerformanceTests/README.md).
Copy file name to clipboardExpand all lines: docs/project-docs/developer-guide.md
+28-7
Original file line number
Diff line number
Diff line change
@@ -18,9 +18,9 @@ Developer Workflow
18
18
The dev workflow describes the [development process](https://github.com/dotnet/buildtools/blob/master/Documentation/Dev-workflow.md) to follow. It is divided into specific tasks that are fast, transparent and easy to understand.
19
19
The tasks are represented in scripts (cmd/sh) in the root of the repo.
20
20
21
-
For more information about the different options that each task has, use the argument `-?` when calling the script. For example:
21
+
For more information about the different options that each task has, use the argument `-help` when calling the script. For example:
@@ -79,6 +86,20 @@ Steps to update `core_manifest.json` and `core_ep-list.tsv`:
79
86
4. Re-enable the skip attribute on the `RegenerateEntryPointCatalog` test.
80
87
5. Commit the updated `core_manifest.json` and `core_ep-list.tsv` files to your branch.
81
88
89
+
### Running specifics unit tests on CI
90
+
91
+
It may be necessary to run only specific unit tests on CI, and perhaps even run these tests back to back multiple times. The steps to run one or more unit tests are as follows:
92
+
1. Set `runSpecific: true` and `innerLoop: false` in [.vsts-dotnet-ci.yml](https://github.com/dotnet/machinelearning/blob/master/.vsts-dotnet-ci.yml) per each build you'd like to run the specifics tests on CI.
93
+
2. Import `Microsoft.ML.TestFrameworkCommon.Attributes` in the unit test files that contain specific unit tests to be run.
94
+
3. Add the `[TestCategory("RunSpecificTest")]` to the unit test(s) you'd like to run specifically.
95
+
96
+
If you would like to run these specific unit test(s) multiple times, do the following for each unit test to run:
97
+
1. Replace the `[Fact]` attribute with `[Theory, IterationData(X)]` where `X` is the number of times to run the unit test.
98
+
2. Add the `int iteration` argument to the unit test you'd like to run multiple times.
99
+
3. Use the `iteration` parameter at least once in the unit test. This may be as simple as printing to console the `iteration` parameter's value.
100
+
101
+
These steps are demonstrated in this demonstrative [commit](https://github.com/dotnet/machinelearning/commit/2fb5f8cfcd2a81f27bc22ac6749f1ce2045e925b).
102
+
82
103
### Running unit tests through VSTest Task & Collecting memory dumps
83
104
84
105
During development, there may also arise a need to debug hanging tests. In this scenario, it can be beneficial to collect the memory dump while a given test is hanging.
0 commit comments