Skip to content

Add unit tests for AnimatedSprite#4744

Merged
bigtimebuddy merged 4 commits intopixijs:devfrom
schipiga:tests/animated-sprite
May 24, 2018
Merged

Add unit tests for AnimatedSprite#4744
bigtimebuddy merged 4 commits intopixijs:devfrom
schipiga:tests/animated-sprite

Conversation

@schipiga
Copy link
Copy Markdown
Contributor

@schipiga schipiga commented Mar 8, 2018

No description provided.

Copy link
Copy Markdown
Member

@bigtimebuddy bigtimebuddy left a comment

Choose a reason for hiding this comment

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

You're on a roll @schipiga. Great addition. It's really good for us to get more coverages on classes like this. Event just basic coverage.

The only thing I would suggest is not checking private properties (ones starting with _), it's more useful to only check the pubic APIs. The result makes for a less brittle test. There are some cases where evaluating a private property is very useful and necessary. In the case of AnimatedSprite and this PR, I'd remove some of the expect lines.

Also, might be useful to ada few more tests to stub out functionality of onComplete, onLoop, etc methods.

expect(this.sprite._currentTime).to.be.equal(0);
expect(this.sprite.playing).to.be.false;

this.sprite.destroy();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Make sure you set this.sprite = null after the destroy

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Btw we dont need destroy() there, because it really doesnt appear in caches and has no generated textures.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

anyway, just add "this.sprite=null" and it'll be fine.

Copy link
Copy Markdown
Contributor Author

@schipiga schipiga Mar 9, 2018

Choose a reason for hiding this comment

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

@ivanpopelyshev maybe stay destroy() anycase for reliability? if in future it will be meaningful we will not need to update tests.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Leave destroy, it doesn’t hurt

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

okey

@bigtimebuddy bigtimebuddy added Type: Enhancement 🥶 Low Priority Generally issues or PRs that don’t need to make it into the next release. labels Mar 8, 2018
@bigtimebuddy bigtimebuddy added this to the v4.7.1 milestone Mar 8, 2018
@schipiga
Copy link
Copy Markdown
Contributor Author

schipiga commented Mar 8, 2018

@bigtimebuddy thank you for review, I will fix it a bit later

@cursedcoder
Copy link
Copy Markdown
Collaborator

That's correct @bigtimebuddy, unit tests by design SHOULD cover only public methods.

@schipiga
Copy link
Copy Markdown
Contributor Author

schipiga commented Mar 9, 2018

unit tests by design SHOULD cover only public methods

@cursedcoder, if you talk about PixiJS design, so maybe. But commonly it depends on context.
For example, if we talk about some complicated method like AnimatedSprite.update which contain 80 lines of code and expanded logic. In future it will be simplier to split it to some small internal methods and cover them separately with understandable and easy-supported tests, rather than try to hug such complex code with unit tests, which seem to be looking not simplier than tested method.

@schipiga schipiga force-pushed the tests/animated-sprite branch from 025b1b6 to 5d91791 Compare March 9, 2018 16:56
@schipiga schipiga force-pushed the tests/animated-sprite branch from 5d91791 to e209623 Compare March 9, 2018 16:58
@schipiga
Copy link
Copy Markdown
Contributor Author

schipiga commented Mar 9, 2018

@bigtimebuddy could you please review it again?

Copy link
Copy Markdown
Member

@bigtimebuddy bigtimebuddy left a comment

Choose a reason for hiding this comment

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

This looks like a good start to me. Again, if we were to add more tests in the future for this class, they might include:

  • Testing currentFrame numbers with gotoAndStop, gotoAndPlay
  • Testing manual update vs autoUpdate
  • Testing onComplete, onFrameChange, onLoop
  • Testing animationSpeed

Doesn't need to be in this PR. We can add as a separate PR

@schipiga
Copy link
Copy Markdown
Contributor Author

schipiga commented Mar 9, 2018

okey :)

@bigtimebuddy bigtimebuddy modified the milestones: v4.7.1, v4.8.0 Mar 14, 2018
@xRosbergx
Copy link
Copy Markdown

How enter in project? Im Brazil :)

@bigtimebuddy bigtimebuddy merged commit 75d9f68 into pixijs:dev May 24, 2018
@bigtimebuddy
Copy link
Copy Markdown
Member

Thanks for all your hard work on these unit-tests @schipiga, sorry they took so long to get in.

bigtimebuddy pushed a commit that referenced this pull request May 24, 2018
@lock
Copy link
Copy Markdown

lock Bot commented May 24, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock Bot locked and limited conversation to collaborators May 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

🥶 Low Priority Generally issues or PRs that don’t need to make it into the next release.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants