-
Notifications
You must be signed in to change notification settings - Fork 11.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added TimeFrame with passed tests #1706
Conversation
contracts/lifecycle/TimeFrame.sol
Outdated
} | ||
|
||
function length(Epoch storage epoch) internal view returns (uint256) { | ||
require(epoch.start <= epoch.end, "Invalid start and end dates"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is we had some sort of 'constructor' to create epochs, which performed these validations? We may also want to force a lower bound on the length (e.g. 30 seconds), to prevent the timestamp manipulation issues already described.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK this one you completely lost me can you explain more
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please explain this one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I didn't see all of the comments on the previous pass!
I meant something like this:
function new(uint256 start, uint256 end) internal pure returns (Epoch) {
require(end >= start + 60); // prevents narrow time frames
return Epoch(start, end);
}
I'm not sure if Solidity provides a way to disable the 'default constructor' for a struct library (probably not), perhaps we can suggest this feature?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems in line with the opaque structs feature we've been dreaming of.
}); | ||
|
||
describe('#hasStarted', () => { | ||
it('it returns true when now if greater than start date', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd personally prefer it if these tests were written in a way that they reflected how the return value of TimeFrame
functions changes as time passes (e.g. using time.increaseTo
), something like:
context before start
it returns false
context after start
beforeEach
time.advanceToStart
it returns true
But that's just an idea, I won't block this PR on that :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love this idea but I have a suggestion on top of that
how about I add another test and this test remains as basic functionalities and second test we call it something like advanceTimeFrame or TimeFrameInAction and there I write 9 test's
1.before start
2.very close to starting (1 millisecond before the start)
3.equal to start
4. A little bit after the start (1 millisecond after the start)
5. middle of the time frame
6.very close to the end (1 millisecond before the end)
7.equal to end
8. A little bit after the end (1 millisecond after the end)
9. after the end
let me know your thought's on that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those seem great (maybe 1 millisecond is a bit overkill 😅), but why would you also keep the basic tests? You'd be testing the exact same functionality on both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whatever you want boss . I make it happen ASAP
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome @catageek, thanks a lot! I left a couple more minor comments.
}); | ||
|
||
describe('#hasStarted', () => { | ||
it('it returns true when now if greater than start date', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those seem great (maybe 1 millisecond is a bit overkill 😅), but why would you also keep the basic tests? You'd be testing the exact same functionality on both.
Supercedes #1592