Ockero icon indicating copy to clipboard operation
Ockero copied to clipboard

Published 20 hours ago • verified publisher icon KogeLabs

Bump spek_version from 2.0.12 to 2.0.16

Open dependabot-preview[bot] opened this issue 3 years ago • 0 comments

Bumps spek_version from 2.0.12 to 2.0.16. Updates spek-dsl-jvm from 2.0.12 to 2.0.16

Release notes

Sourced from spek-dsl-jvm's releases.

2.0.16

  • Add support for IJ 2021.1
  • Move artifact publishing to Maven Central.

2.0.15

Minor release to add support for IJ 2020.3

2.0.14

In 2.0.13 discovery and execution started using coroutines, which means they are not confined to a single thread anymore. This can be problematic as most test frameworks like mokk (and possibly mockito) rely on test execution to be confined in a single thread (#923). Another side effect is that the test execution order wasn't deterministic anymore as at any given point a coroutine can be suspended and control is given elsewhere. This release fixes both that issue, Spek is still using coroutines but the runtime ensures that a given test class will always be confined to a single thread.

2.0.13

This release adds several system properties to control how Spek does discovery and execution.

  1. spek2.discovery.parallel.enabled - controls whether discovery is done in parallel or not, by default it is disabled. The presence of this property regardless of value will enable parallel discovery.

  2. spek2.execution.parallel.enabled - controls whether execution is done in parallel or not, by default it is disabled. The presence of this property regardless of value will enable parallel execution.

  3. spek2.execution.test.timeout - SPEK2_TIMEOUT is now deprecated (will be removed in 2.1.0) and will be replaced by this property. Controls how long a test can run before timing out, by default it is disabled - i.e tests won't timeout.

A note for parallel execution

Parallelism is at a class level not individual test scopes. Spek uses coroutines under the hood to execute tests in parallel, essentially spek2.execution.parallel.enabled just controls which CoroutineDispatcher is used. For parallel executions Dispatchers.Default is used, otherwise the one provided by runBlocking is used.

Commits

Updates spek-runner-junit5 from 2.0.12 to 2.0.16

Release notes

Sourced from spek-runner-junit5's releases.

2.0.16

  • Add support for IJ 2021.1
  • Move artifact publishing to Maven Central.

2.0.15

Minor release to add support for IJ 2020.3

2.0.14

In 2.0.13 discovery and execution started using coroutines, which means they are not confined to a single thread anymore. This can be problematic as most test frameworks like mokk (and possibly mockito) rely on test execution to be confined in a single thread (#923). Another side effect is that the test execution order wasn't deterministic anymore as at any given point a coroutine can be suspended and control is given elsewhere. This release fixes both that issue, Spek is still using coroutines but the runtime ensures that a given test class will always be confined to a single thread.

2.0.13

This release adds several system properties to control how Spek does discovery and execution.

  1. spek2.discovery.parallel.enabled - controls whether discovery is done in parallel or not, by default it is disabled. The presence of this property regardless of value will enable parallel discovery.

  2. spek2.execution.parallel.enabled - controls whether execution is done in parallel or not, by default it is disabled. The presence of this property regardless of value will enable parallel execution.

  3. spek2.execution.test.timeout - SPEK2_TIMEOUT is now deprecated (will be removed in 2.1.0) and will be replaced by this property. Controls how long a test can run before timing out, by default it is disabled - i.e tests won't timeout.

A note for parallel execution

Parallelism is at a class level not individual test scopes. Spek uses coroutines under the hood to execute tests in parallel, essentially spek2.execution.parallel.enabled just controls which CoroutineDispatcher is used. For parallel executions Dispatchers.Default is used, otherwise the one provided by runBlocking is used.

Commits

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
  • @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

  • Update frequency (including time of day and day of week)
  • Pull request limits (per update run and/or open at any time)
  • Out-of-range updates (receive only lockfile updates, if desired)
  • Security updates (receive only security updates, if desired)

dependabot-preview[bot] avatar Apr 14 '21 06:04 dependabot-preview[bot]