-
Notifications
You must be signed in to change notification settings - Fork 1
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
Create and export a test library for primer
and primer-rel8
#273
Comments
As part of this work, there may be a few bits of code that can be generalized to be useful for testing. For example, this expression could be refactored so that we can use it to create test primer/primer/src/Primer/App.hs Line 611 in 0aa8017
|
As mentioned in #281, our big definition which "contains every construct in the Primer language" ( While we're doing that, we should also revisit that definition since it does not, for example, contain any primitive values. While this is likely to be unimportant in its original context ( |
This was partially done in #461, but before I close this, I'd like to make it easier to create |
The `NullDbT` type now properly implements the `MonadDb` spec and behaves as one would expect from a `MonadDb` implementation, save for the fact that it's not backed by a persistent store. As before, do not use this type in production! In this commit, we also test the `NullDbT` implementation fairly thoroughly. This may seem a bit odd for a database implementation that's only intended for testing use itself, but we want to be sure that our core implementation behaves as expected before building more tests on that foundation. There are some serious DRY violations in the test code in this commit. Much of it is copied from our `primer-rel8` tests. We really need to factor out a lot of reusable testing code into a separate lib. (See #273.) However, I'll leave that work for a later PR, as it will require a pretty substantial amount of refactoring.
The `NullDbT` type now properly implements the `MonadDb` spec and behaves as one would expect from a `MonadDb` implementation, save for the fact that it's not backed by a persistent store. As before, do not use this type in production! In this commit, we also test the `NullDbT` implementation fairly thoroughly. This may seem a bit odd for a database implementation that's only intended for testing use itself, but we want to be sure that our core implementation behaves as expected before building more tests on that foundation. There are some serious DRY violations in the test code in this commit. Much of it is copied from our `primer-rel8` tests. We really need to factor out a lot of reusable testing code into a separate lib. (See #273.) However, I'll leave that work for a later PR, as it will require a pretty substantial amount of refactoring.
The `NullDbT` type now properly implements the `MonadDb` spec and behaves as one would expect from a `MonadDb` implementation, save for the fact that it's not backed by a persistent store. As before, do not use this type in production! In this commit, we also test the `NullDbT` implementation fairly thoroughly. This may seem a bit odd for a database implementation that's only intended for testing use itself, but we want to be sure that our core implementation behaves as expected before building more tests on that foundation. There are some serious DRY violations in the test code in this commit. Much of it is copied from our `primer-rel8` tests. We really need to factor out a lot of reusable testing code into a separate lib. (See #273.) However, I'll leave that work for a later PR, as it will require a pretty substantial amount of refactoring.
The `NullDbT` type now properly implements the `MonadDb` spec and behaves as one would expect from a `MonadDb` implementation, save for the fact that it's not backed by a persistent store. As before, do not use this type in production! In this commit, we also test the `NullDbT` implementation fairly thoroughly. This may seem a bit odd for a database implementation that's only intended for testing use itself, but we want to be sure that our core implementation behaves as expected before building more tests on that foundation. There are some serious DRY violations in the test code in this commit. Much of it is copied from our `primer-rel8` tests. We really need to factor out a lot of reusable testing code into a separate lib. (See #273.) However, I'll leave that work for a later PR, as it will require a pretty substantial amount of refactoring.
Some work towards this was done in #625 |
Because our code base is partitioned into 3 separate packages, it would be helpful to export some reusable code for Primer-specific testing from the base modules, which are currently
primer
andprimer-rel8
. This is perhaps a bit unconventional, but it seems like a good idea, in any case.The text was updated successfully, but these errors were encountered: