-
-
Notifications
You must be signed in to change notification settings - Fork 52
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
Lay out tests following the same structure as Yampa #217
Comments
Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Basic in the same order and with the same haddock section separators as they have in Yampa's counterpart.
I've added one such change here: https://github.com/ivanperez-keera/Yampa/tree/develop-tests-orgModules As you can see, the only thing I'm doing is changing the order of definitions in the module, changing the order of tests to match, and adding haddock separators. I used Also, if anyone decides to do this, look at the commit message. You can probably get away with copying the same message, and changing the module name. |
Notes on
|
Notes on
Notes on
Notes on
Notes on
Notes on
|
…217. Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Conditional in the same order and with the same haddock section separators as they have in Yampa's counterpart.
Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Delays in the same order and with the same haddock section separators as they have in Yampa's counterpart.
Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of EventS in the same order and with the same haddock section separators as they have in Yampa's counterpart.
Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Hybrid in the same order and with the same haddock section separators as they have in Yampa's counterpart.
…217. Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Integration in the same order and with the same haddock section separators as they have in Yampa's counterpart.
Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Hybrid in the same order and with the same haddock section separators as they have in Yampa's counterpart.
…217. Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Integration in the same order and with the same haddock section separators as they have in Yampa's counterpart.
…#217. Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of InternalCore in the same order and with the same haddock section separators as they have in Yampa's counterpart.
Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Loop in the same order and with the same haddock section separators as they have in Yampa's counterpart.
Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Scan in the same order and with the same haddock section separators as they have in Yampa's counterpart.
…217. Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Simulation in the same order and with the same haddock section separators as they have in Yampa's counterpart.
Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Switches in the same order and with the same haddock section separators as they have in Yampa's counterpart.
Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Task in the same order and with the same haddock section separators as they have in Yampa's counterpart.
Understanding which parts of Yampa are tested and which ones are not is generally hard. To facilitate keeping track of which elements are tested and which ones are not, this commit organizes the elements of Time in the same order and with the same haddock section separators as they have in Yampa's counterpart.
Notes on
Notes on
Notes on
Notes on
Notes on
Notes on
Notes on
|
The unit tests for the ArrowLoop interface were in issue #217 placed in Test.FRP.Yampa.Loop. However, the ArrowLoop instance is defined in FRP.Yampa.InternalCore, so those tests must be moved. This commit moves all tests pertaining to the ArrowLoop interface to the end of InternalCore, matching the order in which the instance is defined in the corresponding Yampa module.
Understanding which parts of Yampa are tested and which ones are not is generally hard.
There are (at least) two non-exclusive ways to achieve this. We could use some coverage metrics to understand how much of the implementation is covered by the tests. Alternatively, we could just make it trivial to compare a module and their corresponding tests, to determine that indeed unit tests for each published element are included.
I'd like to implement the second, as a simple, lightway approach at keeping tests organized and helping identify which elements of the interface remain to be tested. Therefore, the goal would be to open each module under
yampa-test/tests/Test
, compare it with its corresponding module underyampa/src/
, and organize elements in theyampa-test
module following the same order as inyampa
.As a side effect of this process, it would also be good to identify which elements of the interface are not covered by tests.
The text was updated successfully, but these errors were encountered: