Norman Maurer wrote:
Am Sonntag, den 09.07.2006, 12:25 +0200 schrieb Bernd Fondermann:
Noel J. Bergman wrote:
Bernd, we should have some round-trip testing that would detect this sort of
problem. :-)
What Postage today is already helpful at is building a "clean room"
environment. All mail is kept within. This is good for debugging or
staging to production.
It's not satisfying to see debugging going on on production systems.
What Postage does not support is provide means to inspect its received
emails. I take this as a todo. We would probably want to check headers,
sizes etc.
Until we have that I'd recommend to attach the debugger of your choice
to James (or Postage) to see what's happening.
Bernd
IMHO such a "debugging" should be better done with JUNIT tests...
Postage is great for "performance tests" etc..
Agreed, a unit test would be the best and most lightweight tool to
reproduce and resolve this issue and make sure it does not appear again.
A unit test only focusses one specific class (or small group of classes).
If you want to do end-to-end tests for actually testing your
fully-fledged production server you can no longer rely on your unit tests.
From my experience, the best way to work with a new release would be:
1. Clone production system into test/staging system
2. Change it as slightly as possible into a 'clean-room'.
3. Deploy new James into test system
4. Generate production-like load
5. Run tests
6. no bug: deploy to production
7. Detect and narrow bug
8. Write unit test reproducing the bug
9. Resolve, test, build. goto 3.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
