запустить скалестэйт с отдельным jvm для набора - PullRequest
Новая
       54

запустить скалестэйт с отдельным jvm для набора

0 голосов
/ 04 апреля 2020

Я хотел бы запускать тестовые наборы параллельно с sbt, но каждый набор получает свой выделенный jvm.
(в моем проекте есть один ресурс на jvm, и его нельзя использовать из разных потоков параллельно)

это моя тестовая установка: 

import java.lang.management.ManagementFactory
import org.scalatest.FunSuite

trait BaseTest extends FunSuite {

  test("test1") {
    println(f"process_id: ${ManagementFactory.getRuntimeMXBean.getName} -  thread_id: ${Thread.currentThread.getId}")
    Thread.sleep(5000)
  }
}

class Test1 extends BaseTest
class Test2 extends BaseTest
class Test3 extends BaseTest

и это настройка, которую я пробовал в sbt: 

logBuffered in Test := false //make the logs nicer

parallelExecution in Test := true
fork in Test := true
testForkedParallel in Test := true
concurrentRestrictions in Global := Seq(Tags.limit(Tags.ForkedTestGroup, 4), Tags.limit(Tags.Test, 4))

это то, что печатается, когда я запустить тесты:

идентификатор процесса: 16676@host - идентификатор потока: 13
идентификатор процесса: 16676@host - идентификатор потока: 14
идентификатор процесса: 16676@host - идентификатор потока: 12

тесты выполняются в разных потоках, но все в одном и том же процессе.

Есть ли способ, чтобы у каждого свита была своя собственная jvm?

1 Ответ

2 голосов
/ 04 апреля 2020

Впервые слышу о настройке. В общем, это сложно, так как все инструменты стараются максимально использовать JVM, чтобы сохранить его в тепле.

Вы можете сделать что-то вроде запуска: 

sbt -no-colors --error "print test:definedTests"

, чтобы получить список тестовых наборов. , Если бы я запустил его для одного из моих проектов, я мог бы получить что-то вроде: 

chimneyJVM / Test / definedTests
        Vector(Test io.scalaland.chimney.PatcherSpec : subclass(true, utest.TestSuite), Test io.scalaland.chimney.PBTransformationSpec : subclass(true, utest.TestSuite), Test io.scalaland.chimney.DslSpec : subclass(true, utest.TestSuite), Test io.scalaland.chimney.DslFSpec : subclass(true, utest.TestSuite), Test io.scalaland.chimney.IssuesSpec : subclass(true, utest.TestSuite), Test io.scalaland.chimney.JavaBeansSpec : subclass(true, utest.TestSuite))
chimneyJS / Test / definedTests
        Vector(Test io.scalaland.chimney.PatcherSpec : subclass(true, utest.TestSuite), Test io.scalaland.chimney.PBTransformationSpec : subclass(true, utest.TestSuite), Test io.scalaland.chimney.DslSpec : subclass(true, utest.TestSuite), Test io.scalaland.chimney.DslFSpec : subclass(true, utest.TestSuite), Test io.scalaland.chimney.IssuesSpec : subclass(true, utest.TestSuite), Test io.scalaland.chimney.JavaBeansSpec : subclass(true, utest.TestSuite))
chimneyCatsJVM / Test / definedTests
        Vector(Test io.scalaland.chimney.cats.CatsValidatedSpec : subclass(true, utest.TestSuite))
chimneyCatsJS / Test / definedTests
        Vector(Test io.scalaland.chimney.cats.CatsValidatedSpec : subclass(true, utest.TestSuite))
Test / definedTests
        Vector()

Этот вывод может быть проанализирован чем-то вроде скрипта AWK или Python, чтобы получить список тестовых наборов, сгруппированных по проектам.

В качестве следующего шага, который вы могли бы выполнить для каждого набора проектов: 

sbt $project/testOnly $suite

Это будет запускать каждый набор в отдельном процессе.

ОДНАКО, каждый из этих процессов будет использовать та же самая блокировка в файловой системе, чтобы убедиться, что какой-то другой процесс не будет извлекать коврик из-под него (разумно), но - даже если вы запускаете test:compile прежде, чтобы избежать синхронизации при компиляции - это приведет к чему-то, как я могу только думать, что неэффективно, fr agile беспорядок. Каждый процесс будет выделять память заново (а при большом количестве комплектов это займет много памяти), инициализировать все, все они будут бороться за доступ к одним и тем же ресурсам, и всем им придется согревать JVM с нуля. Могу поспорить, что эта установка будет медленнее, чем последовательное выполнение комплектов в одной JVM, если у вас не было действительно странного варианта использования.

...