Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

startgeek
Copy link

@startgeek startgeek commented Apr 2, 2019

Supercedes #1592

@nventuro nventuro added this to the v2.3 milestone Apr 3, 2019
@nventuro nventuro added contracts Smart contract code. feature New contracts, functions, or helpers. labels Apr 3, 2019
contracts/lifecycle/TimeFrame.sol Outdated Show resolved Hide resolved
contracts/lifecycle/TimeFrame.sol Outdated Show resolved Hide resolved
contracts/lifecycle/TimeFrame.sol Outdated Show resolved Hide resolved
contracts/lifecycle/TimeFrame.sol Outdated Show resolved Hide resolved
contracts/lifecycle/TimeFrame.sol Outdated Show resolved Hide resolved
}

function length(Epoch storage epoch) internal view returns (uint256) {
require(epoch.start <= epoch.end, "Invalid start and end dates");
Copy link
Contributor

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.

Copy link
Author

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

Copy link
Author

@startgeek startgeek Apr 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please explain this one

Copy link
Contributor

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?

Copy link
Contributor

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.

contracts/lifecycle/TimeFrame.sol Outdated Show resolved Hide resolved
test/helpers/expectBNIsWithinDelta.js Outdated Show resolved Hide resolved
test/lifecycle/TimeFrame/TimeFrame.test.js Outdated Show resolved Hide resolved
});

describe('#hasStarted', () => {
it('it returns true when now if greater than start date', async () => {
Copy link
Contributor

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 :)

Copy link
Author

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

Copy link
Contributor

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.

Copy link
Author

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

@frangio frangio removed this from the v2.3 milestone Apr 8, 2019
Copy link
Contributor

@nventuro nventuro left a 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.

contracts/lifecycle/TimeFrame.sol Show resolved Hide resolved
contracts/lifecycle/TimeFrame.sol Outdated Show resolved Hide resolved
});

describe('#hasStarted', () => {
it('it returns true when now if greater than start date', async () => {
Copy link
Contributor

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.

contracts/lifecycle/TimeFrame.sol Outdated Show resolved Hide resolved
contracts/lifecycle/TimeFrame.sol Outdated Show resolved Hide resolved
@frangio frangio changed the title Added TimeFrame with passed test's Added TimeFrame with passed tests Apr 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contracts Smart contract code. feature New contracts, functions, or helpers.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants