I've seen the light! I've decided it's time to start using Unit
Tests. The app i'm most worried about is big and crazy and I don't
have the time to stop development and retroactively build tests for
things that are done(?) - so my plan was to build tests on
development progress from here on, and use regression tests to start
to shoe horn tests into old code as I move forward.
all makes sense so far, right? but it's this regression testing that
has me confused. My understanding is, I want to do regression
testing at a very high level - testing for the symptoms of the bug...
so that if a new bug crops up with similar results it will be caught,
even if it stems from a different underlying problem. well, my app
is a client server app - completely async communication, etc. and
most of the bugs i'm really worried about writing regression tests
for are the ones that show up as a problem between multiple clients
keeping data in sync, or objects unsyncing later... all async stuff
that occurs across multiple applications - they tend to be messaging
problems.
Is there any way to test for these? or do i use the process of
fixing the bug to insert unit tests in all the code i'm changing, and
hope later problems get caught at a lower level?
just as an example... i had a recent bug where new items could be
edited but the changes were only displayed on machines besides the
one that created it.
mike
--
Mike Woodworth
[EMAIL PROTECTED]
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
