You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, testing Material Motion often involves defining one-shot Plans and Performers in test code. This is a ton of boilerplate.
The reason we have to do this is often because we want to verify a side-effect of the performer, but we cannot have a direct reference to it due to the loose Plan/Performer coupling.
To close this issue, we must have a framework in place for testing to be painless. No more creating Plan/Performer classes if possible.
The text was updated successfully, but these errors were encountered:
We might want to consider putting util classes like StepChoreographer into a separate package other than com.google.android.material.motion.runtime to visually separate it from the actual unit tests.
Currently, testing Material Motion often involves defining one-shot Plans and Performers in test code. This is a ton of boilerplate.
The reason we have to do this is often because we want to verify a side-effect of the performer, but we cannot have a direct reference to it due to the loose Plan/Performer coupling.
To close this issue, we must have a framework in place for testing to be painless. No more creating Plan/Performer classes if possible.
The text was updated successfully, but these errors were encountered: