It isn't? Ok, gui stuff aside, the rest can and should be unit-tested.
Unit tests are all well and good, but they do not solve all problems, and
there are many types of testing that unit testing does not begin to address.
Sometimes all that the unit test does is validate your own misconceptions
about the system. There are integration tests and systems test that need to
be performed and these cannot be performed in isolation.
There are also tests that require a different environment then is present
during the unit test, and duplicating this environment is extremely
difficult. And just so you know, we have hundreds of unit tests built into
the project, and they are all run as part of our automated build process.
And to your original complaint...yes, the team got together and discussed
the situation and we decided that it wasn't worth the downside to break up
the solution into a number of smaller solutions; we decided to live with the
long edit/compile/debug cycles and we would look at doing it differently on
the next project. There are problems when you break up a big solution into
numerous small solutions.
In addition, simply doing a compile doesn't take all that long when all that
changes is one project - anywhere from 2 minutes for a minor edit (such as
an E&C would do) to 10-15 minutes, depending on what needs to be built. It
is usually the time it takes to log in to the server, download the latest
bits from the server, download the project that was open, and get to the
point in the session where the problem occurred, that consumes the majority
of the time.
That
aside, your 10minute compile problem is not going away with E&C. You
really
should address that.
You keep throwing the term "you" around - that makes it personal, and for no
good reason. You assumed that the 10 minutes is solely because of the
compile time - I never said it was solely due to compiling. And you are also
assuming that this was "the" problem that I thought E&C would fix. All I
said it would help with that particular irritation.
Weird, I never run into these and believe me, the code I write has a lot
of
layers on top of eachother.
Then you are fortunate.
One example: we do a lot of complex installation code out of custom actions.
The environment that the code is executing in at that time is very different
then the environment that is present under a debugger or out of the
application. Application base paths are different, the appdomain is
configured per the MSI host, and oh-by-the-way, if you are doing an
uninstall/install (otherwise known as an upgrade) the MSI host does not
unload the appdomain used for the uninstall-time custom action before
calling the install-time custom action. This means that assemblies do not
get unloaded, types do not get unloaded, etc. which completely changes the
operating environment of the code. When we write a unit test all it does is
validate the routine as per the environment that exists at the time the unit
test is run, which may be completely different than the environment it is in
at the time the MSI is installed. And this is just one example where a
simple unit test does not fully test a routine.
Unit tests are great when the functionality is entirely self-contained, and
IMO its usefullness diminishes as the amount of interaction with other
components of the system increases. It also decreases in usefulness as the
complexity of the configuration, setup, or complexity of the mock objects
increases. All code has bugs, including the test code. At some point the
complexity of the test negates the usefulness of the results as the
reliability of the result degrades.
There are other examples where unit tests aren't useful.
errr, I was trying to help. Apparently you don't want to be helped. You
describe a problem, that you need a debugger feature to circumvent a
10minute
compile problem. I try to help you with that problem and I get "dont make
assumptions this" and "how on earth do you know that".
Um, errr, I'm sure you really believe you mean well, but it comes across as
condescending and nasty.
I'm sorry David, but
if you don't want me to help you, that's fine, just say so and I can spend
my
time elsewhere.
I'm sure you have something of value to contribute but the way you word
things and the approach you take is needlessly confrontational. I've had
many discussions up here and I've never had this experience with anyone
else.
WTF?! Who's arrogant here!?
You're posts here are. You made an enormous number of assumptions about the
solution, the projects, why it took 10 minutes to get back to a particular
point in a debugging session, if it had unit tests, and the environment it
was running in, my background, and engineering practices in general. You
then compounded this by making additional assumptions about the real cause
of the problem, it's solution, and its implementation. You then worded your
message in such a way that it was imperative, accusatory, superior, and
self-righteous (and note that I am categorizing what you write, not you
personally).
I not only support TDD and unit testing, I am doing a presentation on it to
my company! Yet you have a way of expressing yourself that makes me want to
disagree with your statements even when I agree with them. As I said
earlier, tone it down a notch.
Also, the analogy you used about how Boeing should not use E&C on planes is
flawed. There are a lot of dead test pilots who probably wished the plane
*did* have E&C (or pray&land). Upfront engineering minimizes flaws but it
does not eliminate them.
. A developer sometimes has