Dev-Talk Release 3.0.0

Camunda 7 Topics Discussion & Questions
1

Hi … since we do not use the github issues anymore and I do not feel like opening a jira ticket for every minor discussion, I’d like to discuss some refactorings, design decisions and clean ups with you here … @sdorokhova, will you join me?

2

First: I think we have way to many integration tests in starter … they take forever and sometimes break each other by leaving context and/or db dirty … of course we can always use dirtiesContext, but I would like better to define some scenarios that are tested in one run instead of having ITs for every small possible feature.

3

Hi Jan,

I like the idea about integration tests. It looks like now they’re stable, but I remember having some headache, when trying to add a new one as they were affecting each other, as you said.

Could you start with some proposal and we see, where it goes?

Best regards,
Svetlana

4

Hi.

  • @DirtiesContext can be removed if @TestComponent is used instead of @Component in Tests (e.g. org.camunda.bpm.spring.boot.starter.ProcessApplicationIT.DummyComponent).

  • org.camunda.bpm.spring.boot.starter.util.it.GetAnnotatedBeanTest needs @DirtiesContext or @SpringBootTest(..., properties = { "camunda.bpm.process-engine-name: withNameApplicationEngine" }) because it starts a (new) process application. It seems that process engines or process applications didn’t get unregistered or undeployed by RuntimeContainerDelegate.INSTANCE.get().un... when a (test) context shuts down. Is this a bug or feature? :thinking:

In general reducing the execution time is a good idea but not by removing tests. Spring docs describe

Spring’s test framework caches application contexts between tests. Therefore, as long as your tests share the same configuration (no matter how it is discovered), the potentially time-consuming process of loading the context happens only once.

Therefore test configurations should be structured in a better way so that an application context is stable for more tests.

5

Hi. Today I stumbled into https://app.camunda.com/jira/browse/CAM-8749 (compile scope for camunda-bpm-spring-boot-starter-test in rest and webapp).
This has been fixed for 3.0.0, but:

a) I think this is serious and should be fixed for 2.3.1 as well as it influences the build (test jars included, conflicts (logging,…) possible) and we can not expect everyone to adapt 3.0 on day one since it requires spring boot 2 (which still is a good idea, don’t get me wrong)

b) the starter-test re-compiles camunda-bpm-assertj with java8 and latest assertj, which is useful, but now we have an official camunda supported lib that relies on an “alpha2” version of a community extension … Imho we should either 1) exclude the starter-test from deployment so it is only used in dev or 2) help Martin to release the camunda-bpm-assertj-java8 version so from 3.0 on the spring-boot-starter could have a clean dependency.

6