Tests take time

In yesterday's BTL-WG teleconference I was reminded that the working group had provided some input on some proposed tests I'd revised last summer and that I was due to provide some revisions. Digging in, I found I had revised those tests and submitted them July 2nd, just before I left for a series of trips and vacation that had me away for the month. While I was away the working group reviewed them and submitted comments and revision suggestions -- which got lost in my e-mail and apparently automatically deleted when a month old, before I got to it.

Starting in on the first test, I was advised that the test that should have worked on was a proposed BTL-WG replacement for a Standard 135.1 test. Not sure how I'd missed that -- perhaps I was away when it was originally discussed, or perhaps haste to complete before I disappeared for a month. Regardless, looking up the proposed replacement changed everything.

My revision to the original 135.1 test seemed reasonable, small and in scope. I don't know the provenance of the proposed substitute, but it looks like someone tried to funnel in tests for all sorts of possible adaptive behaviors which, while possible, are outside the scope of the BACnet standard. (And probably unlikely, from my experience writing the software for the capability being tested.)

So I've stripped the test down to its core elements, and replicated it with the necessary modifications for a similar capability. Two simple, straightforward tests instead of one massive monster. We'll see what the working group thinks.

And while I've often been frustrated with the slow pace of standards committees, sometimes this is not a bad thing. It's not always enough just to review the tests; we've learned a lot by applying them to actual devices before casting them in concrete.

Which is why many of my change proposal carry the caveat:

"The subject matter of this proposal ( has X has not) been verified by implementation."