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.0 tests where tests assert certain wording in exception messages as a corrolary. Relying on strings are informative text to not ever change is just not the way I'd prefer to go.
On Fri, Mar 28, 2014 at 1:40 PM, Emmanuel Bernard <emman...@hibernate.org>wrote: > 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.java > > > On 28 Mar 2014, at 13:03, Sanne Grinovero <sa...@hibernate.org> wrote: > > 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 > assertion helper methods. A reset() method to be invoked at the end of > each test (or between tests as needed). > > I'd then remove Log4J from our test dependencies to primarily rely on > assertions only; or for debugging purposes to have it forwards > messages to System.out too - probably enabled by some environment > option - would be good enough. > > On 28 March 2014 11:47, Steve Ebersole <st...@hibernate.org> wrote: > > 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 is pretty light at the moment, I wanted to reach out for > some other ideas/proposals for ways to handle this testing requirement. I > will also reach out to David and James to see if this is something JBoss > Logging itself could help us tackle; maybe there is some feature there > already that would help. Any other ideas/proposals? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
