maxParallelForks controls the parallelism of a single Test task. --parallel controls parallelism for the entire build.
So with maxParallelForks = 4, a single Test could run up to 4 tests in parallel using separate test processes.
Without --parallel, a task in another project (like Checkstyle) wouldn’t be allowed to start until the test task was complete. With --parallel, Gradle tries to run up to --max-workers tasks at once. You’re probably seeing a speed-up because other non-Test tasks are able to run during “idle” moments.
If you’re using a sufficiently new enough version of Gradle (>3.0), Gradle constrains the total amount of work being done to --max-workers. So if you had --max-workers=4 and maxParallelForks=4 and a multi-project build, Gradle could run 1 test worker and 3 tasks or 3 test workers and 1 task or any combination thereof. This prevents a bad situation where you have max workers * max parallel fork test processes running because multiple Test tasks are running at once.
There’s another wrinkle to this. We’re actually trying to make --parallel the default, so certain tasks that are known to be parallel-safe will run in parallel without the --parallel flag. Most the built-in tasks aren’t like this yet, so this is more of a FYI.
You could try creating a build scan and compare the timelines of each build (with and without --parallel).
Regarding forkEvery, you have it right. Gradle will start and tear down a new worker for every test. This is really expensive, so you shouldn’t do this unless you have a really good reason (e.g., globally polluting tests).