Tests parallelism with Scala/Play Framework

#1

Hi,
not sure exactly if I get everything from the 2.0 doc about parallelism.
Atm with a free 1 container plan, I am setting my config to test build and deploy the play framework app on aws beanstalk.
The problem is that our unit tests take about 2h to complete on one machine, if I get things correctly, I can’t really run them on parallel with only one free container right?
Here is my config if let’s say I would have access to 2 containers, how would I proceed?

version: 2
jobs:
  test:
    parallelism: 4
    docker:
      # specify the version you desire here
      - image: circleci/openjdk:8-jdk
    steps:
      - run: circleci tests glob "webservices/test/controllers/*.scala" "webservices/test/controllers/*/*.scala" | circleci tests split
       #- run: cd webservices/ && ./activator test ???

  build:
    docker:
      # specify the version you desire here
      - image: circleci/openjdk:8-jdk

    working_directory: ~/repo

    environment:
      env: dev

    steps:
      - checkout

    ...

0 Likes

#2

That’s correct.

Are your tests CPU bound? If not, you could try doing your own home-made parallelisation by splitting your tests into categories of equal sizes (say two) and then running two processes, so each category of tests are run in parallel. You’re still on one VM, but if your tests are disk-bound or doing a lot of sleeping, it might help speed things up.

0 Likes

#3

thanks,
well they are mainly Play fake app api calls, using Play WSClient and akka under the hood I would say. Not much CPU use I think.
Awaiting the results each time indeed. So running them in // would help for sure.
You mean by running them on different jobs?

0 Likes

#4

No, I meant running them in different processes in one job. I plan to try this for my PHPUnit browser tests at some point (they do a lot of sleeping to wait for screen updates, so they are probably not CPU bound).

It would go something like this, using the & background device:

./test-executor.sh --filter=categoryA &
./test-executor.sh --filter=categoryB &
# wait for processes to end
# print results to stdout
./scan-for-test-finish.sh

Things to consider:

  • you’d have to write the shell scripts yourself
  • you’d have to work out whether your test framework supports some kind of test filtering
  • as before, it’d only be worthwhile if your VM CPU is not already maxed out (take a look with top when your tests are running)

Of course, you can try more than two processes, but once you max out the CPU resource you have, there is no value in adding more.

0 Likes

#5

Hum this means that the runs steps running tests won’t get noticed if tests fail will they?

On the other side, how would I need to complete my config.yml in order to use parallelism (in the case I have 2 containers for ex) ?

0 Likes

#6

Well, you’d have to wire that in yourself. I presume that if scan-for-test-finish.sh returns a non-zero exit code, then your step will fail. There should be a way for it to read the results of the backgrounded tests (e.g. in PHPUnit it can produce “machine readable” output, which is probably XML).

0 Likes

#7

I don’t know. I think the best thing to do there is to upgrade your account and try some stuff from the manual? I assume it would be documented.

0 Likes

closed #8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

0 Likes