I'm trying to execute a JUnit test on an Adobe AEM instance, using the JUnit class. first created arctype maven project
I've defined my testcase inside test folder and was expecting to be able to see it at this URL
http://localhost:4502/system/sling/junit/
It does not show up though.
The test runs correctly with mvn test. also mvn clean install through make a bundle
it's a very simple test case (junit4):
Your JUnit test cases are only executed during your maven builds. They will NOT be accessible over an URL.
I would suggest to use a mocking framework like JMockit, EasyMock, PowerMock or Mockito to mock the server side objects in your JUnit test cases.
The only way you can make something accessible over a URL is by creating SlingServlets. If you really want to execute those test cases using a servlet then create a servlet and call your JUnit test cases from your servlet(which I would not suggest).
Use Mocking frameworks instead.
Related
I have a maven tycho build (which is running fine) and I want now to add the already existing unit tests to the build setup.
The unit tests are organized in a way that each plugin has its test fragment.
All tests are called from a single test suite which contains the tests suites of the fragments and these are containing the actual unit test classes. This is possible due to the Eclipse-ExtensibleAPI: true setting in Manifest.MF
Each test fragment has its pom.xml which contains true to avoid executing tests twice. The test fragments are set as in main pom.xml.
The main test plugin (which contains the main test suite) contains in its pom.xml an target platform extension (which is a feature containing the test fragments).
Now as soon as a tests is called which is written to test a protected method the tycho-surefire throws an java.lang.IllegalAccessException.
In Eclipse the unit tests run fine (as unit tests, not as plugin unit tests!).
I assume that somehow the classes and the test classes are loaded with different class loaders?
Otherwise, since the test is contained in a fragment to the host plugin and the Eclipse-ExtensibleAPI: true should take care that the visibility is such that this should not happen?
Therefor, I would expect tycho to detect fragments and that it is loading them in a way that they have the same visibility?!
Is there a way/strategy to avoid this behaviour?
I know that tycho-surefire tests are executed in an OSGi environment.
But what does that mean regarding class loading of fragments and the IllegalAccessException?
Any help is highly appreciated!
Thanks in advance!
I found the reason why it was not working.
There where two plugins (one containing the ui code, one the domain model code) and one test fragment. The test fragment was referring to the ui code plugin but contained also tests which tested classes from domain model code.
The packages in the test fragment where named the same as where the packages within the two plugins. I can only make a guess but I think that is why it was working with junit called from within eclipse.
Within the OSGi environment the tycho-surefire tests are running this was not working anymore.
To solve this I split the one test fragment into two (one for each plugin), named the packages of the test classes the same as the packages in the plugin and then it worked as expected.
This is also reflected in my short example project on github.
The contents of my jar file does not contain my junit tests. I tried creating a main class that calls my tests with "Junit Core" but that too doesn't get added to my jar file. What am I missing?
Your production package (your jar) is not supposed to contain the test code (your unit tests).
Test code is supposed to be invoked only when the tests are been executed.
You shouldn't do it, but if you want the test code to be included in your package just put it in the same root folder of your production code. Ex: if you are using Maven, your folders structure might be something like this:
project_name/src/main/java/
-> production code
project_name/src/test/java/
-> test code
In that case, change it to:
project_name/src/main/java/
-> production code
-> test code
Be aware that doing that you will have some problems, like the tests not executing during a normal build. We might help you better if you put a question asking how to accomplish your goal (what is your goal?).
Update based on the goal explained in the comments: Would be better if this tool (Silk Central) could run your tests using Maven or Ant, and I'm pretty sure it can.
I've been used different tools to run my Junit (or other XUnit frameworks) tests. What I do is to configure the tool to:
Get the source code from the version control.
Run the build/tests by calling Maven or Ant installed along the tool.
Read the Junit outputs.
Sometimes the tool has its own integration with Junit and you don't have even to use Maven or Ant.
I mean, your central build or tests tool should be able to run your tests just like you do in your own machine.
Take a look on this or search by "Silk Central junit" in the web:
http://community.microfocus.com/borland/test/silk_central/w/wiki/465.zero-maintenance-junit-testing-using-classpathsuite-in-sctm.aspx
I'm going to start using dependency injection in my Eclipse plugin. My test plugin depends on the main one and should use different injection context. Production should work fine standalone (it should have its own injection context), but behave differently when used from tests (should use Junit's injection context).
How could I resolve the injector so that a different one is used in production and in tests?
I don't like the idea to somehow inject context manually in a static variable on test start. Is there a better way? Can extensions be somehow used for that?
I know that in e4 there is a solution for that, but I'm bound to Eclipse Indigo for now and could not find quickly how exactly is that done in latest version. A link to injector configuration with an ability to override in test infrastructure in e4 source is appreciated.
I wound up writing my own JUnit runner modeled largely after the Spring JUnit runner, but would highly recommend looking at the Jukito project now.
At this point I try to have one Guice module per feature, so I end up with one Guice module for test that installs the production module and overrides or binds any external dependencies. I keep that test module in a base test class along with the necessary annotation for the JUnit runner, which is very similar to the JukitoModule examples in the link above.
I want to preform a JUnit tests on my application. I've never done JUnit testing before so I have a couple of (maybe trivial) questions:
Where should I put a test class? I came across with this thread:
Where should I put my JUnit tests?,
and the guy that answers the question is referring to maven projects, but I don't use maven. He explains (in the thread I linked above) that he puts the test class in a different location but in the same package. How can it be done in a GWT project?
How should I execute these tests once they are ready (where in the code to put the execution)?
You should begin by reviewing this: Unit Testing GWT Applications with JUnit.
The other thread is good and reflects the typical JUnit practice, and isn't specific to maven: use a mirror of your package tree under a directory called test. So for instance if your GWT EntryPoint module is located in this directory structure:
project/src/com/myproject/mypackage/MyEntryPoint.java
Then your test code will be here:
project/test/com/myproject/mypackage/MyEntryPointTests.java
If you've created your GWT project using webAppCreator then you should already have a test directory containing the package structure as described.
If you use webAppCreator to create your project, the project can be created with unit testing built-in like so:
webAppCreator -junit -out MyProject com.myproject.mypackage.MyEntryPoint
This will create a test target. If you're using Eclipse, then you should have a Run selection for: Run As -> GWT Unit Test for running your tests.
If you're using ant instead of Eclipse then this should run your unit tests:
ant test
If you didn't use -junit to create the project, the test targets are typically still there, just commented out. Search junit in build.xml to find the targets, and un-comment them.
You need to take a look at this article, MVP1 and MVP2, these are a pattern designs used to Unit Test your application in pure java environment, because using GWT Test Case runs very slow the patterns also has many advantages like separate the logic from the view so you can change the view for Android, for example.
I'm using IBM RAD 7 (aka Eclipse 3.4) and WebSphere 7.
I have an EJB project that contains an #Stateless EntityService and an #Stateless EntityDAO and so on.
I have an Web project that contains a JAX-RS restful web service that looks up the EntityService with this JNDI URL:
ejblocal:entityEAR/entityEJB.jar/EntityService#com.test.EntityServiceLocal
That all works great.
My question is, what would be the "correct" way to write JUnit tests to test the EntityService and EntityDAO classes?
Since the system needs to be running in the WebLogic server to function, I thought I would get the app running, then launch the JUnit test which does a look up of the same JNDI that the web service is using, but I get an error:
Naming Manager ... getURLContext cannot find the factory for this scheme: ejbLocal
Any suggestions are useful, how should I approach writing JUnit tests?
If you're writing Unit Tests, then they shouldn't depend on the container (because they execute only in a JVM) so you can't do JNDI lookups in them. To test your EJB Beans and DAO's with JUnit a Mocking Framework (like EasyMock) can be a great help.
But if you're interested in testing the communication between your EJB's and your REST Services, then you need Integration Tests and I doubt JUnit can help you here. A popular tool for Integration Tests is Selenium, and you need a fully-functional container and enviroment for your tests to execute.
In general, JUnit is intended to write unit tests. Within unit test you verify work of a single component having single responsibility (at least it should have single responsibility :))- all dependencies are mocked somehow (easymock, mockito and so on).
Dependency injection used in EJB simplifies this process - you can instantiate bean in your unit test setUp() method using new operator (you don't need container) and then, inject mocked dependencies (the same way container injects real dependencies).
This is the approach I use. The other thing are integration tests, which verifies entire scenario - starting from webservice (or other remote facade method) call, through beans logic, up to the DB queries. However, in such case you don't verify components standing after webservice/facade. Just webservice output for the specific input.
The good approach is to write test first (failing at the beginning) and then, write the implementation to satisfy it. For unit tests (single bean, tests not run within container) I'd recommend JUnit and EasyMock/Mockito. For integration tests you can use Selenium or JUnit+OpenEJB as a form of simple container for tests (especially if you have remote facade in a form of EJB component). Also, using tools like SoapUI you can create entire tests scenarios for your webservice - post some data, get them, modify, put, againg get, delete and so on.
At the end of the day, I implemented a #Remote remote interface for the Service classes I wanted to test, and did a remote JNDI lookup to the service bean.
More details here:
how to write a JUnit test that can see my EJB service?