[rules-users] Code Coverage

[mike]

Awesome!! thank you very much ... this give me enough ammo for this battle
:)

Cheers
Mike

2012/1/23 Swindells, Thomas <TSwindells at nds.com>

> I don’t think anybody else has bothered to do this. Drools generates the
> classes in memory and they aren’t written on disk – this makes linking with
> the standard instrumentation methods extremely hard if not impossible.****
>
> You may be able to hook into the classloader and/or class creation code to
> pass the bytecode through the instrumentation library if this is really
> needed, but if you tell your manager the cost of doing this they may be
> happy with the alternatives proposed – or just not doing coverage on code.
> ****
>
> ** **
>
> Thomas****
>
> ** **
>
> *From:* rules-users-bounces at lists.jboss.org [mailto:
> rules-users-bounces at lists.jboss.org] *On Behalf Of *mike
> *Sent:* 23 January 2012 16:25
>
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Code Coverage****
>
> ** **
>
> I was wondering if there was any blog post or tutorial on how to set that
> up in jenkins or teamcity or things like that ... it's not a trivial thing
> to do ... also, based on the responses here, doesn't seem like a common
> practice****
>
> ** **
>
> I don't know enough to figure out how to set it up ... as far as i know i
> need to instrument the code ... now, the code, would be whatever drools
> generates ... i don't know how to pickup the package that drools generates
> n' them how to instrument it****
>
> ** **
>
> thank you very much four your time and answers****
>
> cheers****
>
> Mike****
>
> 2012/1/23 Swindells, Thomas <TSwindells at nds.com>****
>
> There is nothing stopping you taking the output and producing a report in
> your CI showing lines (Rules) in red and green as to whether they have been
> touched as part of the tests – if you separate out your rules into a
> separate module you could probably output the report in the exact same
> format as the standard java report xml and get the standard tools to output
> an almost identical report.****
>
>  ****
>
> Thomas****
>
>  ****
>
> *From:* rules-users-bounces at lists.jboss.org [mailto:
> rules-users-bounces at lists.jboss.org] *On Behalf Of *mike
> *Sent:* 23 January 2012 16:14****
>
>
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Code Coverage****
>
>  ****
>
> I could argue this left and right with my managers ... but in reality when
> we mention code coverage we mean looking at a report in CI showing lines of
> code in green or red ... anything short of that is something else****
>
>  ****
>
> Thank you very much for the response ****
>
> Cheers****
>
> Mike****
>
> On Mon, Jan 23, 2012 at 10:47 AM, Wolfgang Laun <wolfgang.laun at gmail.com>
> wrote:****
>
> It is highly recommended as "best practice" to have RHS code that
> doesn't contain any branching instructions. Then, executing means full
> coverage.
>
> In case it is necessary to have more complex code I'd not put it into
> a RHS anyway (where it isn't really OO any more) but I'd code it in
> Java files and just call from the RHS.
>
> For the LHS you can also argue that firing proves coverage; although
> it won't be full *expression* logic coverage, due to potentially
> skipped subexpressions in disjunctions.
>
> -W****
>
>
>
> On 23/01/2012, mike <mikemps at gmail.com> wrote:
> > Thank you very much Thomas ... yes, what i need is standard code coverage
> > ... my company is all over that metric
> >
> > cheers
> > Mike
> >
> > 2012/1/23 Swindells, Thomas <TSwindells at nds.com>
> >****
>
> >>  It depends what you are asking for,********
>
> >>
> >> If you just want to know what proportion of rules you have written have
> >> actually activated then that can be simply achieved by having a
> >> AgendaEventListener and using it to ‘tick’ rules off when they have been
> ****
>
> >> triggered – the blog entry should have you achieve this.****
> >>
> >> ** ******
>
> >>
> >> If you actually want to integrate it with standard java code coverage
> >> reports then this is a different question and is likely to be much
> harder,****
>
> >> if not impossible, ****
> >>
> >> ** **
> >>
> >> Thomas****
> >>
> >> ** **
> >>
> >> *From:* rules-users-bounces at lists.jboss.org [mailto:
> >> rules-users-bounces at lists.jboss.org] *On Behalf Of *mike
> >> *Sent:* 23 January 2012 14:34
> >> *To:* Rules Users List
> >>
> >> *Subject:* Re: [rules-users] Code Coverage****
> >>
> >>  ** ******
>
> >>
> >> Thank you very much ... as far as i know in order to do code coverage i
> >> need to instrument the packages i'm interested in covering ... this****
>
> >> recommendation doesn't take me in that direction****
> >>
> >> ** **
> >>
> >> It is very useful however in showing a way to test rules
> individually.****
> >>
> >> ** **
> >>
> >> Thank you****
> >>
> >> Mike ****
> >>
> >> ** **
> >>
> >> 2012/1/17 Toni Rikkola <toni.rikkola at gmail.com>********
>
> >>
> >> You need to write the coverage tests for JUnit yourself. Test Scenarios
> in****
>
> >> Guvnor do this, but you can't use them outside Guvnor. ****
> >>
> >> ** ******
>
> >>
> >> Test Scenarios get all the rule names for the rules in one package and*
> ***
>
> >> then compares that list to the rules that fired.********
>
> >>
> >> Edson's blog entry might help you
> >>
> http://blog.athico.com/2011/10/cookbook-how-to-test-rules-using-xunit.html
> ****
>
> >> .****
> >>
> >> ** **
> >>
> >> Toni****
> >>
> >> ** **
> >>
> >> On Jan 16, 2012, at 5:49 PM, mike wrote:****
> >>
> >> ** **
> >>
> >>  Hi there,****
> >>
> >> ** ******
>
> >>
> >> I was wondering if its possible to measure code coverage on test running
> ****
>
> >> against a set of rules.****
> >>
> >> ** **
> >>
> >> Thank you****
> >>
> >> Mike****
> >>
> >>  ********
>
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users at lists.jboss.org****
>
> >> https://lists.jboss.org/mailman/listinfo/rules-users****
> >>
> >>  ** ******
>
> >>
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users at lists.jboss.org****
>
> >> https://lists.jboss.org/mailman/listinfo/rules-users****
> >>
> >> ** **
> >>
> >> ------------------------------****
>
> >>
> >>
> >>
> **************************************************************************************
> >> This message is confidential and intended only for the addressee. If you
> >> have received this message in error, please immediately notify the
> >> postmaster at nds.com and delete it from your system as well as any
> copies.
> >> The content of e-mails as well as traffic data may be monitored by NDS
> for
> >> employment and security purposes. To protect the environment please do
> not
> >> print this e-mail unless necessary.
> >>
> >> NDS Limited. Registered Office: One London Road, Staines, Middlesex,
> TW18
> >> 4EX, United Kingdom. A company registered in England and Wales.
> Registered
> >> no. 3080780. VAT no. GB 603 8808 40-00
> >>
> >>
> **************************************************************************************
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >>
> >****
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users****
>
>  ****
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users****
>
> ** **
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120123/b448ae38/attachment.html