Welcome to the latest Developer’s Log. Previously, we concluded with all features completed and initial tests done. With the contracts properly connected, it was time for me to prepare a final suite of end-to-end tests that exercise the system of contracts as a whole (as opposed to testing individual contracts as I was doing before).
The Test Suite
To devise my tests, I adopted various user perspectives and mapped out their potential operations. For instance, a data requester should be able to adjust when data is expected to be ready or cancel a dataset. Users with collateral should be able to stake for a dataset and, post-staking, provide or endorse data, and subsequently dispute or process payments. The goal is to make sure that the combinations that should work actually do, while also ensuring that inappropriate actions are restricted, like providing data without staking.
Testing every possible combination would require around 5,000 tests, four times more than I’ve already written. Many of these involve redundancies and edge cases, especially concerning variations in dataset readiness times. To expedite things, I instead focused on a representative subset of tests that cover most scenarios. I’ll be able to verify more obscure edge cases once the second phase of the beta is underway.
Bug Hunting
After working on individual components for so long, looking at the broader perspective is refreshing. This allows me to think about what a user SHOULD be able to do in a given situation, as opposed to how the code carries out the action itself.
By taking a step back, I am able to spot issues that may have otherwise flown under the radar. Although crafting tests based on these insights can be tedious, it does have its rewarding moments. I really enjoy discovering and fixing a bug that could have potentially been overlooked.
Today, I want to discuss two particular types of bugs, which I will call ‘design flaws’ and ‘extension opportunities’.
Design Flaws
A design flaw is a situation where code executes as planned but doesn’t align with the system’s overall context. It’s when the feature works, but a broader design change is necessary.
Design Flaw, Case Study 1: “Impossible To Bump”
The design I had in mind when implementing this feature was that if an on-time user was providing data and they had been bumped from their spot, then they had a higher priority when looking for spots. So this could, in principle, lead to a chain of events where on-time users are being bumped by other users providing data. That would be fine, however, there was no way for the first on-time user to be bumped, so I don’t have to consider what happens after they’ve been bumped. Thus, I was able to do the simplest thing and scrap a few lines of code handling that edge case, together with the rest of the planned tests.
Design Flaw, Case Study 2: “Accounting for Canceled Data”
The next bug occurred when a creator sets a default time for a batch of data, overrides the default time for all the datasets, cancels the dataset that occurs soonest, then tries to add datasets after the canceled dataset would have started. (An edge case indeed 🤯). In this instance, the creator should still be allowed to add datasets because staking hasn’t started yet. Once I properly took the canceled datasets into consideration, the solution improved the contract’s efficiency and enabled one of the extension opportunities discussed below.
Extension Opportunities
Extension opportunities emerged when optimizations created room for new or previously-shelved features. Given the size constraints of EVM contracts, their feature capacity is limited. Therefore, code optimization and refactoring are crucial to enhance efficiency and potentially reintroduce previously excluded features. This often requires re-evaluation, especially during testing phases. Two such examples include:
Extension Opportunity, Case Study 1: “Changing Decimal Places”
Ensuring the number of decimal places isn’t changed too late presents challenges. For simplicity, values could not, initially, be changed, but later, we considered two options: allowing changes until staking begins or until data is provided. Altering decimals up until data provision risks malicious front-running by creators, potentially compromising submissions, so, we opted to allow changes until staking starts. Due to contract size constraints, however, this feature couldn’t be incorporated. Fortunately, after a major code refactor, we managed to include it.
Extension Opportunity, Case Study 2: “Automatic Clean-Up”
The contract’s size constraints initially prevented efficient tracking for clean-up readiness, primarily counting completed payouts. Tracking canceled datasets was vital, as waiting indefinitely for unfinished ones was not viable. Correcting the earlier design flaw, which improved tracking of canceled datasets, combined with freeing up space from redundant code, enabled smoother tracking and execution of request batch completions.
What’s Coming Next
I know it’s a bit cliche to say, but with the most recent changes the ODO is, from a technical standpoint, the best it’s ever been. Based on how things are shaping up, it appears that Beta Phase 2 test should be shorter than originally expected, creating a smaller gap between its launch and mainnet deployment.
Stay tuned for the next updates coming in November where we’ll share the updates you’ve been waiting for regarding the token, changes to the ODO, the Beta launch, and our updated roadmap.
