I'm writing unit test cases using JMockit for DAOs in my application for which I have to mock the jdbcTemplate of spring so that there will not be any call to the database. I have seen other posts/examples talking about mocking the DAO but never found something that talks about mocking jdbcTemplate. Is there a way I could mock it and if there is one where do I start?
You should mock de DataSource element wich is the one external, also if you check in JDBCTemplate code it execute sentence getting a connection wich is adquired from the DataSource..so you should give a mocked Connection thought the mocked DataSource which gives U what U want in every execution.
Related
I have started using Specflow 3.0 for .NET core tests project with built-in MSTest runner.
I encountered problem while trying to setup one-time method execution in order to persist bearer token value for all running tests in Specflow.
So my idea was to create [BeforeTestRun] Hook static method which would make HTTP request with given credentials. The problem is that those credentials are stored in .runsettings file, so I need to have MSTest's TestContext object in order to access dictionary property.
In Scenario's I'm injecting TestContext and it works fine, however I do not know how to access this object in static [BeforeTestRun] method. Is there any chance to create this object myself and store in static property?
As you see this is abstract class, so I guess Test Framework is automatically injecting concrete implementation in Scanarios with DI. How could I get this concrete implementation?
If solution is not present, would you suggest another approach how could I store configurable settings besides .runsettings so I could access them in static [BeforeTestRun] method without DI?
Thank you
AFAIK I know the behaviour of TestContext in MSTest, you get in plain MSTest for every test your own instance of TestContext.
So you can't get an instance for the whole testrun.
What you could do is, that you do the HTTP request in the BeforeScenario hook of the first scenario that gets executed. There you can get to the TestContext instance without problems.
I work on a codebase that uses the standard "javax.ws.rs.client.ClientBuilder" class, from the CXF distribution, to configure and create a "javax.ws.rs.client.Client".
This works well enough.
I'm now trying to write tests that use JAXRSServerFactoryBean to manage a fake server using a controller defined by an inline class. I can set my host:port to localhost:something, both in the test and in the client configuration, and this works well enough to allow me to test our MessageBodyReaders and Http exception handling.
However, I think this won't be "scalable", as each fake server will have to run on a "dedicated" port (while running the test, at least). I can try to use uncommon ports, and have different tests use different ports, or use random numbers, but that's all somewhat risky. I don't really want CI builds to fail because tests running in parallel ended up using the same port.
I read about the ability in CXF (not JAX-RS) to use "local transport" (https://cwiki.apache.org/confluence/display/CXF20DOC/JAXRS+Testing). It appears that might resolve my problem. I need to verify this, but it's possible that two tests running in parallel both using local transport will not conflict.
However, I can't even get this to work yet, because our client code is using the "standard" JAX-RS client class, not the CXF one. They appear to be different and incompatible.
At the point where I create the client, I tried to do this (just to see if it can work):
WebClient.getConfig(client).getRequestContext().put(LocalConduit.DIRECT_DISPATCH, Boolean.TRUE);
Unfortunately, this fails with "Not a valid Client" in "org.apache.cxf.jaxrs.client.WebClient.getConfig(Object)" because it needs to be an instance of "org.apache.cxf.jaxrs.client.Client", not javax.ws.rs.client.Client.
Is there any easy (or even possible) path forward here?
You can use ClientRequestFilters to unit test JAX-RS clients. Basically register a custom ClientRequestFilter to your Client object (or ClientBuilder) that mocks your response using the abortWith(Response) method on the ClientRequestContext object that is passed in to the filter method.
Something like this should work:
public MyMockRequestFilter implements ClientRequestFilter {
#Override
public void filter(ClientRequestContext requestContext) {
MyEntity entity = // get the entity you want to mock as returned from the server
requestContext.abortWith(Request.ok(entity).build());
}
}
...
ClientBuilder builder = ClientBuilder.newBuilder().register(MyMockRequestFilter .class)
Hope this helps,
Andy
Say, I have a feature in my app that relies on an external API - I provide an interface, which makes calls to my server, and the server, relying on that, makes some calls to some external API and responds something to client. If I wanna write an acceptance test with cucumber for that, how can I stub the calls to that external API, so, e.g. any GET call to https://www.cool-api.io/foo would just immediately return some-predefined JSON response with some predefined headers, any POST request to that url would return a response with some predefined status and headers, etc. How do you do it for acceptance tests if you're using cucumber?
We use WireMock or MockServer for this. You can implement them to stub API calls.
Also, I'd recommend using a framework like Jackson to generate json from domain objects. The benefits of this are not having to maintain json Strings/docs in your code base, and compile time checks on whether you created valid domain objects in your test.
I would probably write my own stub that was able to fake an implementation of the response with the expected content and headers set. If the response object is defined with an interface, then have your hand rolled stub to implement that interface.
Using Mockito for this would probably be to cumbersome in my opinion. Mockito is great, but setting up a complex return value like this may be messy. Hard coding the responses in an implementation of a response interface may be easier.
I would check the actual integration towards the external service using other tooling than Cucumber.
Is it a good practice to use the InMemoryConnection class for unit-testing our Elasticsearch projects?
This class is being used in the actual source code for unit-testing. But the reason I am asking is because it derives from HttpConnection I am not quite sure if it opens any HTTP connection. Our unit tests go to a build server so I would like to avoid that. Thank you for the help.
Yes.
If you look at the implementation of InMemoryConnection, you'll see that it overrides DoSynchronousRequest and DoAsyncRequest (the methdods of HttpConnection that are responsible for actually executing the HTTP request), and simply returns a fake ElasticsearchResponse. No HTTP connections are open and no requests are made, so you are safe to use it in your unit tests.
There is however a NuGet package for real integration tests from c#:
https://www.nuget.org/packages/elasticsearch-inside/
(I'm the author)
How would I go about passing a session to a repository class?
Let's say that the I have two projects.
1) TestSuite
2) BusinessObjects
The repository is contained in the BusinessObjects project. The NHibernate session is opened in the TestSuite project. Now, I want to use the same session since the TestSuite project starts a transaction on that session. Currently, I am using the following:
var repository = new CustomerRepository(_session);
Of course, this looks ugly! I am thinking somehow a dependency injection framework can be hooked and provide me with the ISession object without having to pass into the repository.
In our WCF Service we actually use a UnitOfWork which wraps a single operation and stores the ISession for that operation.
The repositories know how to get an ISession from the current unit of work they are running under.
In terms of testing we have a base test class that any test class which contains tests that touch the database inherits from. We then control the starting and ending of a unit of work in the testfixturesetup. Has worked fairly well for us once you get use to the fact that in the version of NUnit we use teardown is NOT guaranteed to run (in case of an unhandled exception during setup or the test).