I am using EJB 3.0 , Oracle WebLogic.
Need help in the following question :
How to test EJB (3.0) ? I mean unit tests and/or integration tests ? Can I use some kind of embedded EJB container or create a mock for it to write unit tests ? Maybe there is some special test frameworks or aproaches? EJB aren't new for me, but I have never written tests for them.
Any information will be useful for me .
Thanks.
One option is using embedded container. Starts up on every test execution, you have to get your beans through jndi lookup, manage container's configuration yourself and all kind of boring, unproductive stuff.
On the other hand, there are frameworks like Arquillian, that do the thing for you. It supports annotations like #EJB in tests and does DI, manages container.... Read the guide on their website, its worth it.
From my experience, mocks are a no good solution for complex ejb testing, even though it may work on testing some non-container dependant functionality.
My advice is going on it with arquillian.
I would try to use plain junit and mockito as much as possible to test small units of code and use embedded containers only for integration tests as these kind of tests are running much longer as simple unit tests. And for developers running the unit tests should never get annoying.
An embedded EJB Container used in junit tests is a good idea to integration test your servies & ejbs.
Using open-ejb (or any other embedded container like glassfish etc.) helps you to simple write small tests using junit as framework. Even JPA is integrated very well, using a memory database.
If it comes to mocking, let's say for remote services, you may still use mockito inside.
Find some documented & runnable examples here: https://tomee.apache.org/examples-trunk/
Related
I'm confused to say the least. I might be getting Mocks wrong, Test Drivers wrong or maybe both.
My understanding of Mocks is that it's a way of imitating units, to avoid depending on specific parts of your system when testing.
My understanding of Test Drivers is that it's specifically used for Bottom-up integration testing, to imitate High Level Modules, which haven't been implemented yet.
To me that makes Test Drivers sound like a type of Mock, but are Mocks specifically a unit testing thing?
What's the difference between the two?
I understand it in the following way:
Mock:
You have standard layered application, e.g. Controller->Service->Repository. You want to unit test it. So you are using mocks and injecting Repository Mock into Service, so you can isolate Service testing.
Test Driver:
You have same application, Controller->Service->Repository. You did all unit tests and now you want to test Repository Level. It doesn't make much sense to use Mocks during Repository testing because they will not show if your sql queries are correct. So it's time for integration tests. Also you don't want to test entire system ( which may consist of 100 services ), you want to isolate your application, so you are spinning up, let's say, docker container with database ( or embedded database, like h2) and running your queries on this database for testing only.
Same example is applicable for other services clients, e.g. you want to get something by HTTP, and instead of calling real service, you spin up MOCK SERVER, e.g. wiremock.
Drivers are the modules that act as temporary replacement for a calling module and give the same output as that of the actual product.
Drivers are also used when the software needs to interact with an external system and are usually complex than stubs.
To recap:
Mocks are small in memory objects, that have very simple configuration and they used during unit testing for isolation of classes.
Test drivers are more complicated, they are used during integration testing to replace components into your infrastructure for isolation of entire application.
Is there a good way to unit test BMT in EJB 3.x, outside the container. I believe that it would make sense to test transactions right when we are coding it. IMHO it is important to test what we code right from the first possible stage. So, if there is a nice way which is simple and does not take too much time to execute, to test BMT, then it would be really welcome.
At present, I am using an in-memory DB to test my JPAQL in EJB outside the container. I use unitils-DBUnit to inject test data in my DB. So, as the test bed is set, in special scenarios where I need to test the BMT, what should I do?
P.S : I have taken a look into tools like Bitronix, but I am really not sure if it would help my case. I need some tool that is really performance intensive and light so that it does not frustrate the developers - this is unit testing. Kindly give me your inputs on this too. According to you, would such a tool be good for my purpose. If yes, do you also have any examples that I can refer to?
Thanks a lot
Do you really need to test "outside the container", or is "outside the server" sufficient? If the former, have you looked at the embeddable EJB container support in EJB 3.1? The embeddable EJB container runs in a standalone Java process (ideal for unit tests), and BMT is required for the embeddable EJB container per table 27 (section 21.1) of the EJB 3.1 spec.
For unit testing transactions, there should be a complete transaction manager which is standalone and takes very less time to execute. It should not force deployment of any beans or jars.
Bitronix is working fine and satisfies my purpose. It takes less than a second to execute the tests. So, I do not have to mock my transactions anymore and I can be sure that the transactions work as I expect them to work before my code moves to the Integration testing phase. I have also seen positive responses about Atomikos, but I never tried it. May be I can update this thread when I evaluate Atomikos too.
since the dao layer methods will be dependent on data in the database,
in complex systems some operations will depend on lots of tables,
in this way unit test are not repeatable and independent,
i'm wondering how good TDD layers do this? thx.
IMHO you are on to something... If you are communicating with your Sql Server, then you are not doing unit test but integration tests. If you do TDD, then you realise this and start to put server communication into wrappers, so you can stub and mock any test data, instead of using a framework like DbUnit to control database state. I think that Your business logic should not be directly in touch with databases -- or webservices or other external resources. If it is, odds are that you will never write anything but integration tests.
A testing framework like DbUnit is exactly what you want. From their site:
DbUnit is a JUnit extension (also usable with Ant) targeted at database-driven projects that, among other things, puts your database into a known state between test runs. This is an excellent way to avoid the myriad of problems that can occur when one test case corrupts the database and causes subsequent tests to fail or exacerbate the damage.
DbUnit also supports a variety of RDBMS's but I might recommend something like HSQLDB, which can be embedded into your project/tests so your unit tests aren't dependent on being able to connect to a database somewhere in your company's basement. :) Although, on the other hand, you will be testing using a different RDBMS than you would be using in a production environment...
Our installer program is going to be installing a number of system services, under both Windows and UNIX, using JavaServiceWrapper. There will be a class responsible for creating JavaServiceWrapper config files, installing the services, etc.
Can I have some suggestions on how to unit-test this class?
I would not struggle too much with unit testing such a class, rather I would go for integration / smoke tests. You need these anyway to verify that your installation works properly - preferably not only on your own machine, but also in the target environment, in real life, before you are about to demonstrate it to your boss and most important client :-)
Update: I assume that the class in question would not contain much complicated logic, rather just gluing together different pieces supplied by other APIs. However, if this is not the case, and you feel you can't easily test a significant part of its functionality via integration tests, you can still try unit testing with good ol' mocks and/or dependency injection.
Lol! Found this last night. Environmentally Friendly Deployment. I really think as more complex your deployment, the more you need to validate your environment.
What is currently the best tool for JavaME unit testing? I´ve never really used unit testing before (shame on me!), so learning curve is important. I would appreciate some pros and cons with your answer. :)
I think it will depend on what kind of tests are you planning to do. Will you be using continuous integration. Is running tests on handsets a must.
If tests are more logic/data processing tests, the you can do fine with JUnit. But if you need to use some classes from javax.microedition.*, then the things will become a bit tricky, but not impossible.
Some examples: a test for text wrapping on screen, that would need javax.microedition.lcdui.Font. You can't just crate a font class using jars shipped with WTK, because at initialization it will be calling some native methods, that are not available.
For these kind of tests I have created a stub implementation of J2ME. Basically these are my own interpretation of J2ME classes. I can set some preconditions there (for example every character is 5 pixels wide, etc). And it is working really great, because my test only need to know, how J2ME classes respond, not how they are internally implemented.
For networking tests I have used MicroEmulator's networking implementation, and it has also worked out well.
One more issue with unit tests - it is better to have your mobile projects as a java project using Java 4,5,6, because writing test in 1.3 is, at leas for me, a pain in the...
I belive, that starting with JUnit will be just fine, to get up and running. And if some other requirements come up (running tests on handsets), then You can explore alternatives.
I'll be honest, the only unit tester I've used in Java is JUnit and a child project for it named DBUnit for database testing... which I'm assuming you won't need under J2ME.
JUnit's pretty easy to use for unit testing, as long as your IDE supports it (Eclipse has support for JUnit built in). You just mark tests with the #Test annotation (org.junit.Test I think). You can also specify methods that should be run #Before or #After each test, as well as before or after the entire class (with #BeforeClass and #AfterClass).
I've never used JUnit under J2ME, though... I work with J2EE at work.
Never found an outstanding one. You can try to read this document :
how to use it
and here the link to : download it
Made by sony ericsson but work for any J2ME development.
And I would recommend you spend some time learning unit testing in plain Java before attacking unit testing on the mobile platform. This may be a to big to swallow one shoot.
Good luck!
There's a framework called J2MEUnit that you could give a try, but it doesn't look like it's still being actively developed:
http://j2meunit.sourceforge.net