On 28 Jan 2014, at 13:55, Steve Ebersole wrote:
>
> On Mar 28, 2014 7:27 AM, "Hardy Ferentschik" wrote:
> >
> >
> > On 28 Jan 2014, at 12:47, Steve Ebersole wrote:
> >
> > > Given the problems using byteman is causing in CI
> >
> > What problem is that?
>
> Port contention of some sort
Is t
This is not quite the same thing as what I am asking about.
I'd much rather check for the execution of a specific method
(CoreMessageLogger#idClassHadMappingAnnotations, e.g.) as opposed to a
generic method and checking one of its String arguments. We have already
had quite a bit of trouble in 5.
XWiki solved that with a JUnit rule and an in-memory log appender. I beleive
their test adds the log appender programmatically during the tests.
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-test/xwiki-commons-test-simple/src/main/java/org/xwiki/test/LogRule.
On 28 March 2014 12:35, Hardy Ferentschik wrote:
>
> On 28 Jan 2014, at 13:21, Sanne Grinovero wrote:
>
>> On 28 March 2014 12:15, Hardy Ferentschik wrote:
>>>
>>> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
>>>
I'd then remove Log4J from our test dependencies to primarily rely on
>>>
On Mar 28, 2014 7:27 AM, "Hardy Ferentschik" wrote:
>
>
> On 28 Jan 2014, at 12:47, Steve Ebersole wrote:
>
> > Given the problems using byteman is causing in CI
>
> What problem is that?
Port contention of some sort
>
> > and the fact that our
> > reliance on it is pretty light at the moment,
On 28 Jan 2014, at 13:21, Sanne Grinovero wrote:
> On 28 March 2014 12:15, Hardy Ferentschik wrote:
>>
>> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
>>
>>> I'd then remove Log4J from our test dependencies to primarily rely on
>>> assertions only;
>>
>> Why would you do that? I would e
On 28 Jan 2014, at 12:47, Steve Ebersole wrote:
> Given the problems using byteman is causing in CI
What problem is that?
> and the fact that our
> reliance on it is pretty light at the moment, I wanted to reach out for
> some other ideas/proposals for ways to handle this testing requirement.
On 28 March 2014 12:15, Hardy Ferentschik wrote:
>
> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
>
>> I'd then remove Log4J from our test dependencies to primarily rely on
>> assertions only;
>
> Why would you do that? I would expect whatever solution we come up with to
> just delegate to th
On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
> I'd then remove Log4J from our test dependencies to primarily rely on
> assertions only;
Why would you do that? I would expect whatever solution we come up with to
just delegate to the underlying logger.
> or for debugging purposes to have it
I had the same thoughts recently!
My idea would be to have a Logger implementation which logs into an
in-memory buffer, which you can lookup somehow. For my own test needs,
even a static accessor would do. It could be a simple text
representation, or it could store a smarter event-list with some
a
I again have in mind adding some test assertions that a particular logging
(WARN) message gets triggered. We have already one such test in place,
which is one of the places where our usage of byteman comes in.
Given the problems using byteman is causing in CI and the fact that our
reliance on it
11 matches
Mail list logo
