Skip to content

Commit fd78899

Browse files
add the steps to locally run min-max testing (Azure#15335)
Co-authored-by: Bert Ong <823691+beltr0n@users.noreply.github.com>
1 parent 468424d commit fd78899

File tree

1 file changed

+73
-0
lines changed

1 file changed

+73
-0
lines changed
Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
## Min-max dependency testing:
2+
3+
When a library has dependencies with semantic version or semver ranges, how do you ensure and validate that your library actually supports the version ranges you claim? For instance, if we have @azure/keyvault-keys that supports 1.0.0 to 1.0.4 version ranges of @azure/core-http, how would you ensure that this library is actually compatible with all versions of core-http from 1.0.0 to 1.0.4 ( 1.0.0 , 1.0.1, 1.0.2, 1.0.3 and 1.0.4)? One solution is to test the library against each version of the dependency that you claim to support.
4+
5+
But as we keep releasing newer versions, the list of versions that we want to test will keep increasing. Given this, the testing of the entire version range for all dependencies may not always be feasible and we want to find an optimum scalable solution for the dependency testing in this scenario. One approach to this is “min-max” testing, or testing the library against the minimum version of dependency version range and against the maximum version of the dependency version range.
6+
7+
To read in-depth design decisions made during the min-max dependency testing and what it does, read [the blog post](https://devblogs.microsoft.com/azure-sdk/testing-semver-dependency-ranges/).
8+
9+
### Running dependency tests
10+
11+
The minimum and maximum semver dependency testing for Azure SDK packages runs every night along with the nightly live test pipelines.
12+
In order to run the minimum and maximum semver dependency testing **locally on your machine, you can follow these steps:**
13+
14+
### Setup your local dev environment to simulate min/max testing
15+
16+
1. Go to the repo root (e.g. `C:\repos\azure-sdk-for-js`) and run rush update and build package along with all its dependencies.
17+
18+
```
19+
rush update
20+
rush build -t "package-name" --verbose
21+
```
22+
23+
For example:
24+
25+
```
26+
rush build -t "@azure/communication-sms" --verbose
27+
```
28+
29+
2. Install the dependency-testing package dependencies:
30+
31+
```
32+
cd eng\tools\dependency-testing
33+
34+
npm install
35+
```
36+
37+
3. Run the dependency-testing script
38+
39+
```
40+
node index.js --artifact-name "package-name" --version-type "{min | max}" --source-dir "path_to_js_repo" --test-folder "test/public"
41+
```
42+
43+
For example,
44+
45+
```
46+
node index.js --artifact-name "@azure/communication-sms" --version-type "min" --source-dir "C:\repos\azure-sdk-for-js\" --test-folder "test/public"
47+
```
48+
49+
(Note: You may not need to do `npm install` every time you are testing, only once should be enough).
50+
51+
4. Go back to the repo root (e.g. `C:\repos\azure-sdk-for-js`) and run `rush update`
52+
5. Go to your package's `test\public` folder and run these steps from inside it:
53+
54+
```
55+
cd sdk/communication/communication-sms/test/public
56+
rushx build
57+
rushx integration-test:node
58+
```
59+
60+
### Restore your local dev environment
61+
62+
1. Go to your package's `test\public` folder
63+
2. Revert the modified test files: run `git checkout -- .`
64+
3. Delete the uncommitted files added to the test folder: (package.json, tsconfig.json etc.)
65+
4. Delete the `node_modules` folder under the package's `test\public` folder
66+
5. Run the fowing steps from the root of the repo (e.g. `C:\repos\azure-sdk-for-js`)
67+
68+
```
69+
rush update
70+
rush rebuild
71+
```
72+
73+
Note : If the above step fails, you can reset the repo: `git clean -f -x -d` (Warning: this will delete all unversioned files including those ignored by gitignore. Backup any .env files and push any commits you wanted to etc)

0 commit comments

Comments
 (0)