Built Isn’t Proven: Why DFU’s Connections Still Need Proper Testing
Getting code to work once is development. Trusting it with somebody’s business requires a lot more than once.
Dazza Follow-Up has reached an interesting stage.
There is a substantial working product.
There are working connection paths and more connectors being developed.
But I do not want to blur the difference between built and proven.
A happy-path test is the easy test
Connect the right account, give it clean data, leave the internet alone and run the exact sequence the developer expected.
Most software can look pretty good under those conditions.
Real businesses are not that tidy.
The awkward tests matter more
What happens if the user authorises the wrong organisation?
What happens if the provider sends the same event twice?
What happens if a reminder process retries after a timeout?
What happens when a token expires halfway through a job?
What happens if the customer disconnects and reconnects?
What happens if DFU sees something that looks like a follow-up but cannot confidently match it to the right matter?
Those are the tests that turn a connector from an interesting demo into something you can depend on.
Duplicates are not a cosmetic problem
Imagine a system creating the same follow-up twice.
The first one gets completed. The duplicate is still sitting there the next day, so the user chases the customer again.
That is not just untidy software. It can make the business look disorganised.
The same applies to missed follow-ups, stale information and incorrect completion.
These are exactly the boring edge cases that need to be beaten up before release.
DAW testing is part of the next gate
Our wider Dazza testing approach is designed to push beyond “the screen loaded and the button worked”.
The current connector set has not yet had the full testing treatment we want through that process.
So even where implementation has moved forward, we are deliberately keeping the public status conservative.
DFU remains under development.
No release date is the responsible answer
I could pick a date because dates sound decisive.
But a calendar does not make a connection reliable.
The release decision needs to follow evidence from the customer workflows, connector behaviour, security boundaries and regression testing.
Until that work is sufficiently proven, there is no release date being announced.
Built is progress.
Proven is permission to trust it.
We are not going to pretend those are the same thing.
Comments