Wednesday, December 15, 2010

[android-developers] Re: Unit Testing Functional Testing

Nice explanation.

I'll add that when you start testing objects together, that's another
type of testing -- integration testing. For complex interactions, that
can be important to test as well.

A further bit of complexity to the picture, is that, from the outside,
you may have a single object, which from the inside, is a
collaboration of objects. In fact, in a well-designed system, this
will be true at many levels. Generally, unit testing will focus on the
objects near the bottom of this hierarchy, and when the System Under
Test is a collaboration, it won't be involved in its setup. But
anything external that should be injected, should be injected as a
mock object.

I recommend that all such external dependencies by done through an
interface, rather than a class. I have a mock-object package that I've
been meaning to open-source for the past year; I just need to choose
where to host it. It takes an interface, and automatically creates a
mock object out of it. It uses various customizable rules for what to
return from methods; it can create a whole universe of mock objects
starting with one interface, if need be.

Mock objects allow you to not just control the values within the
injected dependency. They also allow you to monitor and report on the
interactions with those mock objects, including values set,
performance, etc. In fact, I have used mock objects as instrumentation
proxies in production systems.

My mock object package provides for partial implementation, as well --
you can provide an object that partially implements an interface,
either as a step toward a complete implementation, or where the
partial implementation is specific to a test. The mock object package
then completes the interface.

Anyway, the point I want to make is that mock objects actually add
considerable power to your testing in a variety of ways. Breaking
dependencies to allow testing in isolation is just part of it. If you
make full use of them, it can considerably enhance and accelerate the
development process, allowing you to create and publish objects to the
rest of the team for integration much earlier, and to test the aspects
your building immediately without having to wait for large pieces of
the system to be completed.

On Dec 15, 4:48 pm, "A. Elk" <lancaster.dambust...@gmail.com> wrote:
> On Dec 15, 12:39 pm, Etienne <lawloretie...@gmail.com> wrote:

> Test-driven development and unit testing require a different and
> sometimes orthogonal mindset to traditional OOP development
> techniques. Sometimes you have to be strict with yourself. If you find
> yourself wanting to control the interaction of two objects in order to
> test them, then you have to mock one of them.

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

No comments:

Post a Comment