The reference app distributed with MVC3 RTM is a great learning tool in that it shows a comprehensive application. but what app (these days) exist without Unit Tests? It doesn't seem possible that the team who poured so much work into providing such a beast wouldn't have employed Unit Tests as they built it. Why not make that work public?
thx
Believe it or not that's how it is. Not a single unit test :-)
Related
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/
I am working on a project in where I decided to use unit tests. This was new to me but after researching I feel pretty confident I am doing it correctly creating mock objects and testing that the correct methods are called. This is working great but now I would like to actually run some tests that use the actual database and external components. How should I go about testing the actual execution of code? I do not want these tests to run when I run all tests. Is there a way to accomplish this using built in testing in vs2012?
Not that I'm aware of.
What you could do is create a separate project for your integration tests and then in the test explorer, separate your tests by class. Or some other logical seperation.
the current implementation that exists seems to specifically have unit testing mainly in mind, but that should change with 2013 and a stronger push towards TDD and Agile development.
Have a look here :http://msdn.microsoft.com/en-us/library/ms243147(v=vs.80).aspx
Scroll down to "Attributes for Identifying and Sorting Tests". There might be something there that's useful that you can use.
We are starting to build infrastructure components in JSF2.0.
What is the best approach for unit testing them?
I tried JSFUnit in the past but wasn't satisfied with it. Is there an easier way to implement it?
This may be more integration testing than unit testing, but if you want to see how your components work in an actual browser, the selenium project has some nice features, and you can do it all through unit tests. You can look it over here: http://seleniumhq.org/docs/03_webdriver.html. I've found that between regular unit tests, unit tests using jmockit or the like, and selenium, I can cover pretty much everything when testing my components.
Cheers,
Bill
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