Expand my Community achievements bar.

SOLVED

CQ5 Junit test cases for OSGI services

Avatar

Former Community Member

Hi,

I am trying to write junit test cases for my osgi services. I tried to follow the below sling testing tool.

http://sling.apache.org/documentation/development/sling-testing-tools.html

But this is not very intuitive.

Here is what I did to set it up .

  1. Added maven dependency.
    <dependency> <groupId>org.apache.sling</groupId> <artifactId>org.apache.sling.junit.core</artifactId> <version>1.0.8</version> </dependency>
  2.  Install the bundle from Felix console.

Now I tried accessing http://localhost:8080/system/sling/junit/ but this gives 404 error. 

Am I missing anything here ?

1 Accepted Solution

Avatar

Correct answer by
Former Community Member

Many OSGi services can be successfully [unit] tested outside of the run-time, that is, they are just POJO so you can test them using JUnit and your favourite mocking framework (e.g. EasyMock). If you need dependency injection, that's no problem either. Whilst in-context testing is certainly very important, so I'm not advocating you don't need do that as well, you can get a long way (catch most bugs early following TDD) by eliminating your external dependencies including complex run-time set-up. Once you are happy that all of your unit tests pass locally, by all means deploy to your OSGi run-time and repeat (along with any integration (black-box) tests).

HTHs

Fraser.

View solution in original post

2 Replies

Avatar

Level 10

Some basic verifications !

is 'Apache Sling Junit Core' bundle is installed and active ?

is test folder included in your bundle ?

does your testcases configured to RunWith SlingRemoteTestRunner.class ?

Avatar

Correct answer by
Former Community Member

Many OSGi services can be successfully [unit] tested outside of the run-time, that is, they are just POJO so you can test them using JUnit and your favourite mocking framework (e.g. EasyMock). If you need dependency injection, that's no problem either. Whilst in-context testing is certainly very important, so I'm not advocating you don't need do that as well, you can get a long way (catch most bugs early following TDD) by eliminating your external dependencies including complex run-time set-up. Once you are happy that all of your unit tests pass locally, by all means deploy to your OSGi run-time and repeat (along with any integration (black-box) tests).

HTHs

Fraser.

The following has evaluated to null or missing: ==> liqladmin("SELECT id, value FROM metrics WHERE id = 'net_accepted_solutions' and user.id = '${acceptedAnswer.author.id}'").data.items [in template "analytics-container" at line 83, column 41] ---- Tip: It's the step after the last dot that caused this error, not those before it. ---- Tip: If the failing expression is known to be legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: #assign answerAuthorNetSolutions = li... [in template "analytics-container" at line 83, column 5] ----