Seb is correct, and just to ensure that you get an answer to your question, short of doing something in native code (and I am pretty sure that would not work) or modifying the bytecode of the class at runtime, and creating the class that overrides the method at runtime, I cannot see a way to alter the "finalness" of a method. Reflection will not help you here.

are you referring to Aspect-oriented aka AOP? any idea if AOP can change the access to non-final?
–
zeroin23Apr 15 '09 at 11:08

I wasn't really meaning AOP, not sure if it can do it, I was thinking more along the lines of jakarta.apache.org/bcel. However, if somehting is hard to do there is probably a reason for it... and generally hard things should not be done :-)
–
TofuBeerApr 15 '09 at 14:27

If your unit test case can't create Foo due to other dependencies, that might be a sign that you're not making your unit test right in the first place.

Unit tests are meant to test under the same circumstances a production code would run, so I'd suggest recreating the same production environment inside your tests. Otherwise, your tests wouldn't be complete.

That is not what unit tests are for. Unit tests are for extremely granular units of code. What you're describing sounds more like integration tests or possibly functional tests.
–
Hank GayApr 14 '09 at 16:40

Not necessarily; I don't know the specific circumstances in which he's working (i.e. other classes, DB, etc.), but there are certain tests you can do with many classes at once - for example, if you're using an external library, it's ok to assume it's working ok and use all its clases in your tests.
–
SebApr 14 '09 at 16:47

3

Yeah, there are "certain tests you can do with many classes at once". Those aren't unit tests. Still useful, and important to do, but they aren't unit tests.
–
Adam JaskiewiczApr 14 '09 at 17:05

1

"Unit", "smoke", "integration", "black box", "white box", etc. are all distractions from the original question. The dev wants to figure out whether or not they can substitute an alternative method for the framework's final. I think this exposes a flawed dependency that requires some refactoring.
–
gregturnApr 14 '09 at 17:45

1

gregturn> actually the dependency was expressed intentionally as the framework dev did not want anyone to override it. Yes, you have summarised nicely my intend. thx 8)
–
zeroin23Apr 15 '09 at 11:20