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

Create and export a test library for primer and primer-rel8 #273

Closed
dhess opened this issue Mar 2, 2022 · 4 comments · Fixed by #758
Closed

Create and export a test library for primer and primer-rel8 #273

dhess opened this issue Mar 2, 2022 · 4 comments · Fixed by #758
Assignees
Labels
enhancement New feature or request primer Specific to the primer package primer-rel8 Specific to the primer-rel8 package testing Related to tests/testing

Comments

@dhess
Copy link
Member

dhess commented Mar 2, 2022

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 and primer-rel8. This is perhaps a bit unconventional, but it seems like a good idea, in any case.

@dhess dhess added enhancement New feature or request testing Related to tests/testing primer Specific to the primer package primer-rel8 Specific to the primer-rel8 package labels Mar 2, 2022
@dhess dhess self-assigned this Mar 2, 2022
@dhess
Copy link
Member Author

dhess commented Mar 4, 2022

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 Apps directly:

(defaultDefs, defaultDefsNextId) =

@georgefst
Copy link
Contributor

As mentioned in #281, our big definition which "contains every construct in the Primer language" (TestUtils.testASTDef) is duplicated and we should factor this out.

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 (Tests.Action.Available.test_1), in some other tests (e.g. serialization) we will want to be sure to exercise all primitive types. Alternatively, to prevent it becoming too unwieldy, it may be preferable to instead have a set of definitions which, between them, cover all constructors in Primer.

@dhess
Copy link
Member Author

dhess commented Jun 7, 2022

This was partially done in #461, but before I close this, I'd like to make it easier to create Apps for testing.

dhess added a commit that referenced this issue Jun 21, 2022
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.
dhess added a commit that referenced this issue Jun 21, 2022
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.
dhess added a commit that referenced this issue Jun 21, 2022
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.
dhess added a commit that referenced this issue Jun 21, 2022
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.
@brprice
Copy link
Contributor

brprice commented Sep 13, 2022

Some work towards this was done in #625

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request primer Specific to the primer package primer-rel8 Specific to the primer-rel8 package testing Related to tests/testing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants