If instantiating a real object is a problem (again assuming immutable and without side-effects) then you might need to break up your objects a bit more.
I'm on the fence regarding public fields though; there are cases where they're just more readable but then you do sometimes end up having to switch away from them and refactoring all clients might be impossible. On Wed, Feb 16, 2011 at 11:26 AM, Fabrizio Giudici <[email protected]> wrote: > On 02/16/2011 12:14 PM, Ricky Clarkson wrote: >> >> Generally, you don't need to mock immutable objects that have no side >> effects, just as you wouldn't mock Math.max > > If I have a test on Person that only needs first and last name I'm forced to > instantiate a real object instead of mocking it. If I later add new fields, > I'm forced to update the tests where I don't need them. Generically > speaking, I can't have Person to implement an interface, or e.g. having > virtual proxies for some fields etc... > > -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > java.net/blog/fabriziogiudici - www.tidalwave.it/people > [email protected] > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
