JMeter - JUnit Request execute all methods - junit

In JMeter JUnit Request I must choose Test method to define component:
Test method: The method to test. Required: Yes
How can I execute all methods in class? Isn't a way to define less than X JUnit Requests per method? it seems excessive, is there other way as using Java request?

This is by design, the purpose of JUnit Request sampler is to measure execution time of a single method.
If you are looking for a way to execute all methods in a given class and measure their cumulative execution time there are at least 2 ways:
Create as many JUnit Request samplers as many methods you have in your test and put them all under Transaction Controller
Use JSR223 Sampler and develop custom code to run your JUnit methods:
Using JUnit Computer class like:
import org.junit.runner.Computer
import org.junit.runner.JUnitCore
def computer = new Computer()
def jUnitCore = new JUnitCore()
jUnitCore.run(computer, Foo.class)
Using Java Reflection Api like:
import org.apache.commons.lang3.reflect.MethodUtils
import org.junit.Test
import java.lang.reflect.Method
Class junitClass = Class.forName('Foo')
Object t = junitClass.newInstance()
List<Method> testMethods = MethodUtils.getMethodsListWithAnnotation(junitClass, Test, false, true)
testMethods.each { method ->
method.invoke(t, null)
}
Replace Foo with the fully qualified name of your JUnit class in both examples in order to get it to work.

Related

NiFi: How to develop a JUnit test of NiFi controller service?

I am developing a NiFi controller service, and this controller service has a property of another controller service which is dbcpservice.
Accoding to the source code in github.com/apache/nifi, controller service test depends on processor test too, that means define a TestProcessor which has a property of self-defined controller service, and then operate the the controller service through this processor.
But in my case, my controller service's property is another controller service(dbcpservice), I do not know how to write a junit test to set the controller service.
You can create a simple processor via anonymous inner classes (or named classes) in your test in order to exercise the behavior of your controller service. For example, DBCPServiceTest does this by defining TestProcessor alongside the test class. All that test processor needs is a property descriptor which accepts a controller service of the same type as the system under test (SUT) -- in this case, your custom controller service.
If you're asking how to configure your custom service (CustomService from here on), you pass parameters to the TestRunner instance, like so:
final TestRunner runner = TestRunners.newTestRunner(TestProcessor.class);
final CustomService service = new CustomService();
service.setNestedService(new NestedService());
final Map<String, String> properties = new HashMap<String, String>();
runner.addControllerService("custom-service-id", service, properties);
In addition to Andy's answer - you could also create a test processor with Mockito:
AbstractProcessor processor = new Mockito().spy(AbstractProcessor.class);
TestRunner testRunner = TestRunners.newTestRunner(processor);

Programmatically instantiate a FeignClient for tests

I have a dead simple FeignClient interface that I would like to "unit"/integration test with a fake HTTP server, WireMock for example. The idea is to test the mapping with a sampled HTTP API response, without configuring a whole Spring Boot/Cloud Context.
#FeignClient(name = "foo", url = "${foo.url}")
public interface FooClient {
#RequestMapping(value = "/foo/{foo-id}/bar", method = RequestMethod.GET)
public Bar getBar(#PathVariable("foo-id") String fooId);
}
Is there any way to programmatically instantiate this interface, like a Spring Data Repository through a *RepositoryFactoryBean ?
I see a FeignClientFactoryBean in the source code, but it is package protected, and it relies on an ApplicationContext object to retrieve its dependencies anyway.
Well, you can fake a real rest client using wiremock for testing purposes, but this is more about containing the functional test, that feign clients themself work. This is mostly not what you really want to test, because the actual need is to test your components using your client behave in a specified way.
The best practice for me is not to make live hard with maintaing a fake server, but mock the clients behavior with Mockito. If you use Spring Boot 1.4.0, here is the way to go:
Consider you have some FooBarService, which internally uses your FooClient to peform some FooBarService::someAction(String fooId), which performs some business logic which needs to work with a foo with given id
#RunWith(SpringRunner.class)
#SpringBootTest(classes = App.class)
class FooUnitTest {
#Autowired;
private FooBarService fooBarService;
#MockBean;
private FooClient fooClient;
#Test
public void testService() {
given(fooClient.getBar("1")).willReturn(new Bar(...));
fooBarService.someAction("1");
//assert here, that someAction did what it supposed to do for that bar
}
}
At this point you first should clarify, what you expect the REST client to respond, when asking for "/foo/1/bar", by creating a mock for exactly that case and give the Bar object you expect to receive for that API, and assert that your application is in the desired state.

Guice injection leaking into other tests

I use Guice to instantiate a VocabularyAPI object for one of my unit tests unitTest1(). However, for another test (unitTest2()), I simply use mockito's #Mock annotation to mock an instance of the same class - VocabularyAPI.
I noticed that when I only run unitTest2() - mockito's mock setting for my VocabularyAPI is configured correctly. However, when I run the entire test suite (both unitTest1() and unitTest2()), both the tests are instantiated with the settings from the injector.
How can I limit the scope of the injected object to only inside the test that it is being injected? I want to be able to use the injected object in unitTest1() and mocked object for unitTest2().
Any problems in using local variables?
In unitTest1():
VocabularyAPI vocabularyAPI = // inject (I'm not familiar with Guice)
In unitTest2():
VocabularyAPI vocabularyAPI = Mockito.mock(VocabularyAPI.class);

Can I start a junit test from an intellij plugin

I have a database that stores my test results. I'm interested in writing a plugin for intellij13 that will let me rerun the test failures from the database using the JUnit run configuration. I can't find any documentation on this.
I'd like to see an example for some method like:
public void runTest(String testClass, String testName) {...}
I looked into IntelliJ 13.x and I was able to create JUnit runtime configuration. You need to do the following.
In your META-INF/plugin.xml add dependency on JUnit plugin, otherwise necessary JUnit plugin classes will not be available in your plugin class loader.
<depends optional="false">JUnit</depends>
Here's the sample code to create JUnit runtime configuration. Although it works, it is just a stub, you will have to populate all attributes.
import com.intellij.execution.RunManager;
import com.intellij.execution.impl.RunManagerImpl;
import com.intellij.execution.impl.RunnerAndConfigurationSettingsImpl;
import com.intellij.execution.junit.JUnitConfigurationType;
import com.intellij.openapi.project.Project;
...
RunManagerImpl runManager = (RunManagerImpl) RunManager.getInstance(project);
JUnitConfigurationType type = JUnitConfigurationType.getInstance();
RunnerAndConfigurationSettingsImpl runnerAndConfigurationSettings = (RunnerAndConfigurationSettingsImpl)runManager.createRunConfiguration("junit test run", type.getConfigurationFactories()[0]);
runManager.addConfiguration(runnerAndConfigurationSettings, false);
And here we go, JUnit run configuration.

How do I unit test a Grails service that uses a converter?

I have a Grails service that sends out e-mails using a 3rd-party service by doing a HTTP call:
class EmailService {
def sendEmail(values) {
def valueJson = values as JSON
... // does HTTP call to 3rd party service
}
}
I've written a unit test to test this service (because an integration test spins up Hibernate and the entire domain framework, which I don't need):
#TestFor(EmailService)
class EmailServiceTests {
void testEmailServiceWorks() {
def values = [test: 'test', test2: 'test2']
service.sendEmail(values)
}
}
However, when I execute this unit test, it fails with this exception when it tries to do the as JSON conversion:
org.apache.commons.lang.UnhandledException: org.codehaus.groovy.grails.web.converters.exceptions.ConverterException: Unconvertable Object of class: java.util.LinkedHashMap
I then re-wrote my unit test to just do the following:
void testEmailServiceWorks() {
def value = [test: 'test', test2: 'test2']
def valueJson = value as JSON
}
And I get the same exception when it tries to do the as JSON conversion.
Does anyone know why I'm getting this exception, and how I can fix it?
Even though you are testing a service, you can apply the #TestMixin(ControllerUnitTestMixin) annotation to your test class to get Grails to set up the JSON converter.
The as JSON magic is created when the domain framework spins up.
You have to either change your test to an integration one or mock the asType.
def setUp(){
java.util.LinkedHashMap.metaClass.asType = { Class c ->
new grails.converters."$c"(delegate)
}
}
Rember to clean up after yourself in the tearDown, you wouldn't want metaprogramming leaks in your test suite.
def tearDown(){
java.util.LinkedHashMap.metaClass.asType = null
}
Edit:
If you come from the future, consider this answer: https://stackoverflow.com/a/15485593/194932
As Grails 3.3.x grails-test-mixins plugin is deprecated. #see migration guide.
For this problem you should implement GrailsWebUnitTest which is coming from Grails Testing Support Framework.
you can initialise the JSON in the setUp() . There are various marshallers which implement ObjectMarshaller , which need to be added to the ConverterConfiguration for JSON conversion to work.
http://grails.github.io/grails-doc/2.4.4/api/index.html?org/codehaus/groovy/grails/web/converters/marshaller/json/package-summary.html
example :
DefaultConverterConfiguration<JSON> defaultConverterConfig = new DefaultConverterConfiguration<JSON>()
defaultConverterConfig.registerObjectMarshaller(new CollectionMarshaller())
defaultConverterConfig.registerObjectMarshaller(new MapMarshaller())
defaultConverterConfig.registerObjectMarshaller(new GenericJavaBeanMarshaller())
ConvertersConfigurationHolder.setTheadLocalConverterConfiguration(JSON.class, defaultConverterConfig);
I just ran into this, and I really didn't want to implement GrailsWebUnitTest as recommended in another answer here. I want to keep my service test as "pure" and lean as possible. I ended up doing this:
void setupSpec() {
defineBeans(new ConvertersGrailsPlugin())
}
void cleanupSpec() {
ConvertersConfigurationHolder.clear()
}
This is how it happens under the hood when you implement GrailsWebUnitTest (via WebSetupSpecInterceptor and WebCleanupSpecInterceptor).
That said, the converters seem to be meant for use in the web tier, primarily for making it easy to transparently return data in different formats from a controller. It's worth considering why the service you're testing needs the converters in the first place.
For example, in my case, someone used the JSON converter to serialize some data to a string so it could be stored in a single field in the database. That doesn't seem like an appropriate user of the converters, so I plan on changing how it's done. Making the converters available in my service test is a temporary solution to allow me to improve our test coverage before I refactor things.
I was getting the same error when trying to unit test a controller that calls "render myMap as JSON". We use Grails 1.3.7 and none of the other solutions worked for me without introducing other problems. Upgrading Grails was not an alternative for us at the moment.
My solution was to use JSONBuilder instead of "as JSON", like this:
render(contentType: "application/json", {myMap})
See http://docs.grails.org/latest/guide/theWebLayer.html#moreOnJSONBuilder
(I realize this is old, but came here in search for a solution and so might others)