How much unit testing will be usefull depends in a large part on how general your units are.

In a closely coupled system, a unit that never directly receives a user's input will have it's inputs "protected" by other units. It can rely (in an ideal world) that it's inputs will be in a range it can handle - and they won't contain any tests to verify it is so (why should they - the other units have handled it). Such systems are more efficient, but more difficult to extend and maintain. But they can be tested through functional testing alone - because in a way, the whole script is one big unit.

If, on the other hand, your project consists of more general units, which are only loosely coupled with other units, then each unit must be able to check that it's assumptions about the inputs (and the state of the system) are valid. That means that the unit should be tested for conditions which can not happen when it is coupled with other units.

Yes, the loosely coupled systems are less "efficient", they are much easier to extend, maintain.

If your project is large, you will be much happier if you find a way to break it down into more-or-less independent units. If you don't, eventualy your project will behave like a bowl of spaghetti: you won't be able to fix one end of the project without something moving at some other end. If you do, however, you will need to implement unit testing, too.


In reply to Re: Functional and Unit Test Redundancy by matija
in thread Functional and Unit Test Redundancy by saintbrie

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":