I have some message consumers that take dependencies through the constructor, and I would like to cover them in unit tests. Does MassTransit's test harness provide a way to register consumers with constructor parameters?
You can specify a factory method, or a consumer factory, when creating a consumer test harness.
harness.Consumer<T>(() => new T());
You can find the three standard extension methods in the code:
https://github.com/MassTransit/MassTransit/blob/develop/src/MassTransit/Testing/ConsumerTestHarnessExtensions.cs#L35
UPDATE:
MassTransit now has container support for the test harness
Related
I am reading Spring integration source code, and I have some questions understanding the workflow:
Does the #SpringBootApplication class, when calling application.run(), will call directly beans annotated using #ServiceActivator ? For example in my config file I have :
#Bean
#ServiceActivator(inputChannel = test)
public MessageHandler myHandler() {
return new SomeHandler();
}
when the application.run() is fired, the method handleRequestMessage() of SomeHandler will be called ? Am I understanding it right ?
Well, you need to understand that there are two parts of this matter:
Configuration phase when Spring parses all the annotations to register beans in the AppplicaitonContext. This way even that #ServiceActivator is consulted and a event-driven endpoint is registered as a bean as well.
Runtime part of Spring Integration environment. Here the mentioned endpoint is subscribed to the inputChannel and when message is has arrived the handleRequestMessage() is triggered from that SomeHandler. That's why it is called "service activator".
You probably need to make yourself familiar with EIP first of all: https://www.enterpriseintegrationpatterns.com/ to understand what is messaging and why there are endpoints and channels in between. Then you go to Spring Integration docs: https://docs.spring.io/spring-integration/docs/current/reference/html/index.html and realize for yourself that this framework provides a bunch of out-of-the-box components for this or that EIP which may be registered automaticaly in the application context by just declaring some annotation.
I have a cucumber test setup with spring boot. There are a large number of integration tests which take a while to run. Because they share a database, the new threaded mode in cucumber 4+ does not work (as expected).
Ideally this would work in Junit also.
For each test, I would like to create a dynamic datasource with a new database/datasource instance that the test can use independently of others, allowing it to run multithreaded (and use the 12 cores I have available).
I have tried #Scope("cucumber-glue") and #Scope("prototype") on the DataSource bean, but this results in org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'dataSource': Requested bean is currently in creation: Is there an unresolvable circular reference?.
If I use the prototype scope, the bean creation method gets called each time, but gives this error, as does the glue scope.
I have also added #DirtiesContext(classMode = DirtiesContext.ClassMode.BEFORE_EACH_TEST_METHOD) to classes and methods, without the scope, but this seems to do nothing.
Is there a way I can either:
1. create a new datasource for each test and have hibernate create the tables?
2. pool a set of datasources that could be used by tests?
3. Populate/reinitialize the context accordingly?
A side consequence of this is that I don't believe my context is getting recreated properly between tests for other instances of the scoping.
#Configuration
public class H2DynamicDataSource {
#Autowired
private Environment env;
#Bean
#Scope("prototype")
public DataSource dataSource() {
return new EmbeddedDatabaseBuilder()
.setType(EmbeddedDatabaseType.H2)
.build();
}
}
Cheers
R
Hopefully you've solved this.
I just went through something similar and felt like cruising around SlackOverflow to see if anyone was doing something similar (or perhaps asking about how to do something like this) and saw this post. Figured this would be a good place to drop this information in case anyone else tries to go down this road.
I think your asking two questions:
How to get multithreading working with Cucumber and Junit Cucumber?
multithreading works great but you are constrained to a single lane
of test execution by junit if your using either the Cucumber or
SpringJUnit4ClassRunner runner junit runner classes. (I suspect this is why #CucumberOptions doesnt contain a thread arg. It's useless with the current Cucumber runner implementation.)
In order to get this working I had to write my own test runner that
would defer a the entire test execution to Cucumbers Runtime
object. I used a custom cucumber plugin to cache the results and
then relay those results back to junit when asked to 'run' the
individual tests. With Cucumber behind the wheel I was able to allow
any arbitrary number of threads for my tests.
How to ensure a new spring datasource for each test?
If you're unfamiliar with how Spring cache's contexts for tests you should have a look through the documentation here https://docs.spring.io/spring/docs/current/spring-framework-reference/testing.html#testcontext-ctx-management-caching but the tl;dr: Spring's TestContextManager(this is whats under the hood of Springs junit runner) will create and store a spring context in a map keyed by your test configuration. DirtiesContext will force the context to reload.. but otherwise two tests with the same parent class are effectively guaranteed to execute in the same test context. If your datasource is a spring datasource that is initialized during boot.. you definitely need to refresh this context between tests.
Putting those two concepts together.. Cucumber-Spring provides a way to create a new context (consistent with cucumbers new 'world' per test design) for every test but it does so by disregarding any existing spring contexts or data contained therein. This may actually be helpful to you if you can trust Cucumber-Spring to correctly stand up your datasource for you.. but in my situation we had a bunch of issues using this fake context and really needed to pull objects from the default spring context. In my case I had to incorporate Springs TestContextManager into my custom plugin AND write my own Cucumber BackendSupplierimplementation to hijack Cucumbers dependency injection mechanism (effectively replacing Cucumber-Spring)
All in all, what your trying to do is a major PITA and I hope the Cucumber folks make this easier at some point.. but what your trying to do is definitely possible. Hope you got it working!
I’m looking for some guidance on the best way of writing integration (ie tests for entire Spring Boot Application) for Spring Cloud Task.
Based on existing documentation and samples I see two approaches for this:
1) Use the standard #SpringBootTest with #TestPropertySource(properties = {"spring.cloud.task.closecontext_enable=false"}
as described here
http://docs.spring.io/spring-cloud-task/docs/1.2.0.M2/reference/htmlsingle/#_writing_your_test
This seems to allow effectively only one test per test class as the task is run when the spring context is initialized ie once per test class. However
#Autowiring of beans in the context into the test class should work to eg to check the results of the task, or examine the state of the task repository.
2) Use SpringApplication.run(MyTaskApplication.class, myArguments); in each test method as in the example here
https://github.com/spring-cloud/spring-cloud-task/blob/master/spring-cloud-task-samples/batch-job/src/test/java/io/spring/BatchJobApplicationTests.java
This allows me to write multiple tests in the test class each with potentially different spring properties or batch job parameters.
The main problem I have with either approach that I can’t see how to get access eg #Autowire to beans in the context such as JdbcTemplate (eg to insert test input data for a job into an embedded db) or RestTemplate (to set up expectations using MockRestServiceServer)
after these beans are created but BEFORE the task is run - is this possible? If not it’s hard to see how to write meaningful integration tests for tasks.
What Ive done for now is a variation on approach (2) above (ie I can run the task more than once / have multiple tests in the same test class)
I'm using
SpringApplication application = new SpringApplication(new Object[] {MyTaskApplication.class, TestConfig.class});
TestConfig is defined with #TestConfiguration in the test class and contains mock beans etc overriding the actual beans
I then use
application.addListeners()
to add a ContextRefreshedEventListener which allows me to set expectations on mocks (or execute jdbc calls) after the beans are created but before the task is run.
(I have a generic Listener class that allows me to pass in the behaviour as a lambda or method reference per bean)
Then run the task with
application.run(args);
(can use different args in different tests)
I can also pass "--spring.cloud.task.closecontext_enable=false" as an argument to keep the application open if i want to verify mocks / db state after the test runs. In this case I close it manually at the end of the test.
If this seems a sensible approach it might be useful if Spring Cloud Task itself provided some sort of generic listener or hook to allow the setting of test state between bean creation and task execution.
I am using SpringJUnit4ClassRunner in my unit test and the test can access autowired beans (mocked services) properly.
How ever it tests a Job that also talks to the services. The job also has the beans autowired.
Sadly inside the "new Job().execute(...)" call from within the test, the autowired services inside the Job are null.
Can anyone suggest/guess what is going wrong !?
Instances not created and managed by Spring will not be injected with their dependencies by Spring (unless you apply some AspectJ magic).
As the Job instance is created by the application, you will have to manually inject its dependencies. Simply set mocks, or autowire the beans required by Job in the test class and pass them to the newly created instance.
I want write an integration test but with one minor restriction. I got a TimeSourceBean that I want to mock out. This TimeSourceBean is used several times deep in the application. (no way to do this with reflection)
Everything is done by autowire.
I think I could load in my test an additional XML with an implementation I like to have.
see: here!
But really nice would be when I can create my mock TimeSourceBean in the test itself and register it (replace the original bean) to the context
=> so before I start the test, I create the mock and register my bean like this:
context.registerBean(timeSourceBeanMockVersion);
Any ideas if this is possible?
You can add an other bean/class that implement the same interface (hopefully you use them), and mark this other bean class as #Primary.
But then you need to make sure that this primary bean is only loaded in the test cases you need them.