Hey Holly,

well sure, for interactive tests (how i'd call it) we've used a scenario
where we just stop within test execution and debug things using a remote
shell or any other means.
Instead of halting standard tests, you can also use a feature known as
"serverMode". This may sounds silly, but exactly does what you want:
It does not shutdown the framework automatically. A good example is this [1]

This is a demo on how we actually used the Pax Exam DSL to creating a OSGi
environment used as a normal container, that you just start. In this case
you won't get the helper bundles installed automatically.
To get the idea on whats really going on, just compare the two factory
methods defaultTestSystemOptions() vs defaultServerSystemOptions() in [2].
See, much less defaults you don't care about when not really injecting test
bundles anyway.

Not sure on how deep you've went with Pax Exam so far, you really want to
understand the concepts described in [1]. Otherwise the examples i
mentioned before might not make sense immediately (speaking of the plumbing
API vs. porcelain API. You want to understand plumbing cause its really
useful when creating new usecases other than automatic testing).

Hope this helps ?

[1]
https://github.com/tonit/Learn-PaxExam/blob/master/lesson-servermode/src/main/java/org/ops4j/pax/exam/servermode/SimpleServer.java

[2]
https://github.com/ops4j/org.ops4j.pax.exam2/blob/master/core/pax-exam-spi/src/main/java/org/ops4j/pax/exam/spi/PaxExamRuntime.java

[3] https://github.com/tonit/Learn-PaxExam

Happy Easter Holidays,
Toni

On Thu, Apr 5, 2012 at 12:41 AM, Holly Cummins <
holly.k.cumm...@googlemail.com> wrote:

> Hi Toni,
>
> Good question. I realised I usually do use the NativeContainer, which may
> be why I never noticed the trick about re-using the downloaded bundles and
> configuration until recently! In either case, though, what's usually most
> useful to me is an OSGi console, rather than an attached debugger. Thinking
> about it more, I suppose I could use a debugger to suspend the test and
> then telnet in to an Equinox console if I have my options set correctly. Is
> that the sort of approach you'd recommend, or is there something simpler?
>
>
> On Wed, Apr 4, 2012 at 9:18 PM, Toni Menzel <toni.men...@rebaze.com>wrote:
>
>> Hi Holly,
>> Just a quick reply, did you consider using NativeContainer ? Just because
>> it simplifies debugging really.
>> On general approaches, i will reply in detail tomorrow. (Soccer now ;)
>> Cheers,
>> Toni
>>
>> On Wed, Apr 4, 2012 at 9:57 PM, Holly Cummins <
>> holly.k.cumm...@googlemail.com> wrote:
>>
>>> Hello,
>>>
>>> When running pax-exam tests, I find most of my failures are caused by
>>> bundles failing to start for one reason or another. I have two strategies
>>> for figuring out the issues, but I don't think either is quite what I'm
>>> supposed to be doing:
>>>
>>> (1) Exhaustive assertion approach: In my test code, I add assertions
>>> that all of the bundles I care about are started. If a bundle isn't
>>> started, I try and start it and use the error message as the message for a
>>> test failure. This makes for tests with very clear failure messages, but it
>>> means writing a lot of boilerplate code. If I forget to add an assertion
>>> for a problem bundle, my system is still a black box, and I need ...
>>>
>>> ... (2) Sneaky backdoor console approach: Often, what I really want to
>>> do is just open a console to the test framework and have a good browse of
>>> what's started and what's not and which packages and services are
>>> available. In these cases, I find the temporary folder pax-runner is using
>>> and fire up a console using a command like
>>>
>>>              java -jar bundles/org.eclipse.osgi_3.5.1.R35x_v20090827.jar
>>> -console -configuration equinox/
>>>
>>> This makes it really easy to diagnose what's gone wrong in a failing
>>> system, but it doesn't feel like I'm using the pax tools as intended.
>>>
>>> Am I missing some elegant debugging technique that everyone else using
>>> pax-exam knows about? In other words, is there a cleaner way to produce a
>>> dump of which bundles failed to resolve for technique (1), or to easily
>>> bring up a console of the test environment for technique (2) using proper
>>> pax-runner, rather than just ferreting out pax-runner's temporary folders
>>> and using them directly?
>>>
>>> Thanks,
>>> Holly
>>>
>>> _______________________________________________
>>> general mailing list
>>> general@lists.ops4j.org
>>> http://lists.ops4j.org/mailman/listinfo/general
>>>
>>>
>>
>>
>> --
>> --
>> Toni Menzel | Founder | Rebaze GmbH
>> toni.men...@rebaze.com | www.rebaze.com
>>
>>
>>
>> _______________________________________________
>> general mailing list
>> general@lists.ops4j.org
>> http://lists.ops4j.org/mailman/listinfo/general
>>
>>
>
> _______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general
>
>


-- 
-- 
Toni Menzel | Founder | Rebaze GmbH
toni.men...@rebaze.com | www.rebaze.com
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general

Reply via email to