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
10 matches
Mail list logo
