Different modules for test and production

[Søren Bramer Schmidt]

Hi Oleg

In our setup we use a different module in test and production. One issue we run into is that it is very easy to add a binding to the test module and forget to add the binding to the production module. As Scaldi does not rely on the type system, this means that we won't catch the mistake before releasing to production.

Do you have some general recommendations on how to deal with this situation?

[Alexandre Bedrytski]

Hi Soren,

Normally, if you are using a dependency in your code and this binding is not defined in a module, there will be a runtime exception.

So your question is how to have this exception on compile-time instead of the runtime, am I right?

Alex

[Søren Bramer Schmidt]

Hi Alex

Our code goes through a series of steps before reaching end users. Currently these steps are:

1) Local development

2) local unit tests

3) ci build

4) ci unit tests

5) release to staging environment (where we could manually test the application or run proper integration tests, but currently doesn't)

6) release to end users.

We catch most errors in 1 & 2 with the occasional bug surfacing in 3 & 4 when shared libraries are updated at an unfortunate time.

Missing bindings however only surface in 1 & 5 & 6 because we use a different module in tests.

We can catch this by doing manual tests in 1 or 5 but I really want to have that process automated.

As you say, it would be great if the typesystem could catch the missing binding, but I don't see how that would be possible. So basically I would like to understand how others deal with this.

As an added note I would prefer to keep out build pipeline as simple as possible, so would rather avoid introducing integration testing in step 5 if at all possible.

Venlig Hilsen
Søren

--
You received this message because you are subscribed to a topic in the Google Groups "scaldi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scaldi/svN44JsVC0g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scaldi+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aliaksandr Bedrytski]

Hi Soren,

There are no specific "compile-time" checks in Scaldi (as in Guice or Subcut).

You may check Macwire for this kind of functionality (it uses macros for compile-time checking).

Otherwise it is possible to create separate unit tests to verify if all production bindings are set up.

Obviously this has a problem of initializing production bindings in test environment, but I don't see other way

to automatically test it, to be honest.

To unsubscribe from this group and all its topics, send an email to scaldi+un...@googlegroups.com.

[Oleg Ilyenko]

Yeah, I would agree with Alexandre. Scaldi is a runtime DI library, so it will not give you much safety at a compile time. The cake pattern or Macwire can help you in this respect.

For testing I suggest to check the docs http://scaldi.org/learn/#testing. So the general idea is to use you main application module (the one that production application uses) and override some bindings if necessary. If you are using a typesafe-config or similar config library, then you can put most of the configuration, like DB URLs, credentials, etc. in there. Scaldi have native support for typesafe-config and java properties. Although unit-tests are useful and fast, in my opinion, it is also very helpful in most applications  to have a set of integration tests which involve starting the whole application (or just instantiating all production modules) with a test configuration (which, for instance uses some test database, test queues, etc. These also can be created on-the-fly for every test, if necessary). I personally will do it for any kind of application, regardless whether it uses a compile-time or a run-time DI library. These integration tests will ensure that the application modules are configured correctly.

Hope this helps