Add documentation for new parallel testing suite #2153
Conversation
docs/docs/contributing/workflow.md
Outdated
| ``` | ||
|
|
||
| Currently this will re-run some unit tests and do some preprocessing because of | ||
| the way partest has been set up. | ||
| As you can see, the `filterTest` task takes a regular expression as its |
There was a problem hiding this comment.
The filterTest task takes a regular expression as its argument. For example, you could run a negative and a positive test with:
> filterTest (.*pos/t210.scala)|(.*neg/t210.scala)
docs/docs/contributing/testing.md
Outdated
| Running all tests in Dotty is as simple as: | ||
|
|
||
| ```bash | ||
| $ sbt |
docs/docs/contributing/testing.md
Outdated
|
|
||
| ## Unit tests | ||
| These tests can be found in `<sub-project>/test` and are used to check | ||
| functionality of specific parts of the codebase in isolation, such e.g. |
There was a problem hiding this comment.
such e.g., very test, wow
docs/docs/contributing/testing.md
Outdated
| > testOnly absolute.path.to.TestClass | ||
| ``` | ||
|
|
||
| To filter out individual tests you can use: |
There was a problem hiding this comment.
You can further restrict the executed tests to a subset of TestClass methods as follows:
docs/docs/contributing/testing.md
Outdated
| ``` | ||
|
|
||
| ## Integration tests | ||
| These tests are source files compiled by Dotty with an expected amount of |
There was a problem hiding this comment.
These tests are Scala source files expected to compile with Dotty (pos tests), along with their expected output (run tests) or errors (neg tests).
docs/docs/contributing/testing.md
Outdated
| - `partest` will bootstrap the compiler, run the unit tests and then the | ||
| integration tests | ||
|
|
||
| ## dotty partest |
There was a problem hiding this comment.
dotty test suite?
docs/docs/contributing/testing.md
Outdated
|
|
||
| ## dotty partest | ||
| The new test suite will soon become the standard integration test runner. It | ||
| has several advantages over the old implementation. |
docs/docs/contributing/testing.md
Outdated
| - integrates with JUnit, without the need for setup | ||
| - reuses the same VM for compilation | ||
| - can filter tests | ||
| - much faster than scala-partest (almost 2x) |
There was a problem hiding this comment.
runs much faster (almost 2x)
docs/docs/contributing/testing.md
Outdated
|
|
||
| - integrates with JUnit, without the need for setup | ||
| - reuses the same VM for compilation | ||
| - can filter tests |
There was a problem hiding this comment.
allows filtering of tests
| by using: | ||
|
|
||
| ```bash | ||
| > filterTest .*i2147.scala |
There was a problem hiding this comment.
What do you think about using testOnly for both by class name and by regex filtering?
There was a problem hiding this comment.
I think that would be cool. Please implement 
felixmulder
force-pushed
the
topic/dottest-userman
branch
from
0e772dd to
29ff5ad
Compare
| as follows: | ||
|
|
||
| ```bash | ||
| > testOnly absolute.path.to.TestClass -- *methodName |
There was a problem hiding this comment.
Can you explain the * here?
There was a problem hiding this comment.
> testOnlyt path.toTestClass -- -z subStringOfMethod
> testOnlyt path.toTestClass -- -t exactMethodName
From what I gather the *methodName is equivalent to -z methodName
There was a problem hiding this comment.
Should I include this instead?
There was a problem hiding this comment.
I not sure it's better, but it might be a bit confusing to have both .* and * in the such similar places
There was a problem hiding this comment.
Decided to merge this so that @abeln can base his docs update on it.
I'll get to the docs again once I've fixed the deadlock situation.
No description provided.