How much is too much byte code changing?

[uptown]

JO already uses javassist which modifies the byte code of the code under test. I can imagine that some may argue that because during the tests code has been changed on the fly that the testing is not valid because the code under test is not the exact code which will be ran in released builds. The less the change in code for testing, the weaker the arguement becomes. So is there such a thing as "too much byte code manipulation"?

[deje]

Yea Ive heard this argument from a few people in the community, against JO.

But let's examine this a bit:

* JO does not alter the lexical structure of the program
* JO does not use proxies to replace properties or classes (so you are working on YOUR objects as they are)
* JO adds monitors for callback triggering, which treats objects as immutable

So in essence, the added bytecode ONLY ever affects the timing of call-stacks returning. Now, this is not guaranteed anyway (the garbage collector creates the very same issues). Since JO is NOT a performance profiler, and JO-instrumented binaries are never used in production I think this is a moot point.

The purists who argue that the class "is not the same" after bytecode instrumentation are splitting hairs. Every framework out there instruments class bytecode liberally: Hibernate, AspectJ, Hivemind, JBoss Seam yada and none of these are altering the lexical semantics of the program. That's all JO (and indeed any unit testing toolkit) claims to verify.

Now, there's a valid argument to be made about using AOP weaving with JO, the point being that AOP can REPLACE existing code ("around()" advice). And this we need to think about a bit.

[deje]

also should be noted that JO allows you to us object tests without any bytecode manipulation via the assertState() and assertStateChain() methods (though they are buggy atm).

But this may not be so easy with design patterns.

[uptown]

Yeah the Aspect Oriented Programming (AOP) was really what i was thinking about after doing some reading on what it actually involves it appears using AOP could be extremely useful but may introduce more byte code manipulation than wanted. We can come back to this dicussion later once we get more into the details of if/how we will use AOP in JO.