Ask Questions and Find Answers

Can anyone help with applying unit test cases on service builder or mvc action,render and resource commands in liferay 7. I referred the docs but was only able to find details of applying unit test on a normal class in liferay 7.

Where would you like to have the answer? Here, on the community slack, or where else did you crosspost?
Please don't crosspost - it just generates duplicate work and nobody has a hint that the question might already be discussed or even solved elsewhere

I'm facing the same issue. There are no enough resources in the Liferay documentation on how to apply unit test cases on service builder or mvc action,render and resource commands in Liferay 7. It  will be helpful if you provide some useful resources in this thread. 

I also have the same issue to apply unit test cases on Service Builder, Portlet etc. rather than just on simple java code. Kindly give some real example or reference to do that if possible. Thanks.

Hi Bony,Even I was searching for a same kind of thing i.e I just want to apply junit testing in a liferay mvcPortlet in Liferay 7(Specifically 7.2), I have explored certain blogs but all of them are for older versions. So if anyone is having any solution regarding the same please answer the question or provide some reference for the same.Thank you.

There is one solution that worked for me,When you will try to test your MVC Portlet you will get error something like "ClassDefNotFound",So, you have to change few things in build gradle file of your MVC PortletChange compileOnly group: "com.liferay.portal", name: "com.liferay.portal.kernel"
    compileOnly group: "com.liferay.portal", name: "com.liferay.util.taglib"
    compileOnly group: "javax.portlet", name: "portlet-api"
    compileOnly group: "javax.servlet", name: "javax.servlet-api"
    compileOnly group: "jstl", name: "jstl"
    compileOnly group: "org.osgi", name: "org.osgi.service.component.annotations"
to
compile group: "com.liferay.portal", name: "com.liferay.portal.kernel"
    compile group: "com.liferay.portal", name: "com.liferay.util.taglib"
    compile group: "javax.portlet", name: "portlet-api"
    compile group: "javax.servlet", name: "javax.servlet-api"
    compile group: "jstl", name: "jstl"
    compile group: "org.osgi", name: "org.osgi.service.component.annotations"

which means change compileOnly to compileIt will work...Hopefully.....

Yes it worked for me, hope it works for others as well
Thank you Darshan Jethwani.

While I'm a strict proponent for unit tests, there are a couple of aspects that I like to keep in mind:
Your portlets (controllers) follow  the portlet spec, thus the interface will be much more broad that you like in a typical unit test. Also, what they trigger in the backend (assuming it'll be service builder) will be significantly hard to simulate - especially from a unit test point of view. In the end, it's code that translates one API to another.
As you can't deal with this fact by changing the interfaces, you're kind of stuck. If you need meaningful work in your controller, I'm advocating extracting this "meaning ful work" into its own method or class, independent of the portlet spec, and test the heck out of that class.
Same with ServiceBuilder code. It's inherently hard to unit test a *LocalServiceImpl implementation if all it does is to translate a method call to the persistence API. If you do more stuff, extract it, to abstract away the interfaces it uses. This way you'll be able to test it without any running runtime and without database.
I'm saying this, as you specifically asked about unit tests. For integration tests (which can be done with JUnit, thus the names blend into each other) there might be a different answer. For me personally a unit test is not allowed to rely on a surrounding application server or a database.
I like my controllers and service builder code to be at a complexity level that's good to be reviewed, but not fully unit tested - due to the reasons given above. And that's despite considering myself to be a strict warrior for intensive testing: The code that is worth being tested should be extracted into its own class. But whenever you'll have to adhere to a given class/interface/outside world, it'll be inherently hard to write meaningful, maintainable unit tests.