Spring org.springframework.restdocs.RestDocumentation class override apply method of org.junit.rules.TestRule which implies that all test cases should be written in Junit. How can i achieve the same functionality using TestNG.
There's not built-in support for using TestNG at the moment. You might be interested in this issue which is tracking the possibility of adding it.
Related
I was reading about code-injection at run-time and there are many tools/APIs available like Javassist, GluonJ and AspectJ which provide features to inject code. However, I did not understand purpose for injecting code at run-time while we can do override behaviors by sub-classing in Java. With Javassist and GluonJ, I can create classes at run-time but why does anyone do that, in the first place? Can anyone please help me to understand the difference and purpose of code injection ?
Code injection is usually used into application that are used to modify/check/trace other software. In Java we usually reffer to this kind of library as Bytecode modification libraries so if you look on the internet you will probably find more information under this name.
Here I listed a couple of examples of big and famous projects that I now are using Bytecode modification into their cores:
Evosuite: this project takes an application in input and generates unit test for it. Code injection is used to explore the desired project and dependencies and traceability
JaCoCO: this project is a tool for Java project. It is supposed to be attached to your application and once you run your JUnit tests it is going to generate a report on the coverage achieved. Obviously here code injection is necessary to trace every method call made during test execution.
Ie. I have a GUI package, and a Logic package.
How can I prevent the Logic classes from importing GUI classes? Others(or myself) working on the same project might do that, which I want to prevent.
A solution could for example be a check in JUnit, that fails if its done, or a runtime check that throws an exception. Something along these lines, but how to do it?
You can write such a test using JDepend or DependencyFinder or Degraph.
Degraph is the only of the three tools that explicitly is intended to actually write tests for cases like this. Also AFAIK JDepend does not find all dependencies in more recent Java Versions (like classes mentioned in Annotations).
I'm the author of Degraph so I'm obivously biased.
I created the JabSaw project. It allows you to define modules by using annotated classes and to express the relationships between the modules. By default, a module contains all classes in a single package.The restrictions can be checked using a Maven plugin, from the command line or from a unit test. This should solve your problem.
One solution which comes to my mind is make GUI classes package private. Although you cannot isolate only one package and say, only Logic classes cannot use GUI, but other can.
Lately I've been using a lot of JUnit tests which have the predefined names for methods I will need to implement in my code. I find the "Create method 'x'" tool very useful but I was wondering if there was a tool that creates all the undefined methods, would anyone happen to know? This really isn't a huge problem but it would be very convenient for me to just add all of the missing methods at once as opposed to one by one.
I'm afraid that is not possible. Eclipse is able to generate all methods which you need to implement an interface, but you do not seem to have an interface here. If I understand your scenario right, you get Unit-Tests which do not compile because your class does not provide the tested methods yet.
When the class exists already, then Eclipse should suggest you to create a method with the needed signature. That is what you probably mean with "one by one".
In your case the fastest way is:
create the class
go into your unit test
jump through all non-compiling methods using command + . and create the methods using auto-suggest
I would like to use Google Guice (2.0 or 3.0, does not matter) for my Netbeans Platform Project. My Project has several Netbeans Modules. I managed to use Guice in a single Netbeans Module, but now I want to Inject a Dependency from one NBModule to another. Is this possible? I googled a lot and searched the mailing lists of netbeans and guice, but it seems like noone ever tried this.
I do not want to use the Lookup API for this, because I really need Dependency Injection for better testing.
Has anyone experiences with that?
Edit: To be more specific: Can i Use the same Injector for all NBModules or do I have to create an Injector for every Module?
I realize that this question is old, but since the subject is still relevant I decided to share my findings.
We successfully use Google Guice 3.0 in our Netbeans Platform project. This includes injecting dependencies across NBMs using one injector. The only issue we encountered was that Guice didn't recognize annotations in other NBMs, because they were loaded through other classloaders. See http://tkills.blogspot.com/2014/08/using-google-guice-in-netbeans-rcp.html for details.
I have not worked with Netbeans RCP, only with Eclipse RCP and with integration with Spring. We had to have separate Springs application context for every plugin, with one root context that was shared between all other plugins. So you would need similar thing, separate injectors for every modul. I am not sure but i thing Guice does not support concept of including one injector to another as parent injector.
How can I use the profiler from NetBeans 6.8 or 6.9 (choosing 'entire application') with guice enhanced classes?
I am using google guice 2.0 (with warp persist 2.0-20090214) for some classes and wanted to profile those classes. But I cannot see a result for those classes. The only result I can see is for one method 'EnhancedClass.access$000' which is not very helpful. Other classes are working.
Does somebody know a workaround? Or know what I am doing wrong?
The profiler produces these ugly results because there is no source code available to NetBeans for the enhanced classes. So you need to avoid that Guice needs to produce these classes in the first place by
breaking the circular dependency (-ies) that cause them,
or if you are using the AOP features of Guice I think you're out of luck