Add a simplified central object to act as porcelain for the mock#10
Draft
eds-collabora wants to merge 4 commits intocollabora:mainfrom
Draft
Add a simplified central object to act as porcelain for the mock#10eds-collabora wants to merge 4 commits intocollabora:mainfrom
eds-collabora wants to merge 4 commits intocollabora:mainfrom
Conversation
This was previously the central object in the API, and it's still usable as such (in a more flexible mode). But we're about to add a simplified and more streamlined central object, so we need to rename this one. It functions as a wiremock server object, so Server makes sense as the new name. Signed-off-by: Ed Smith <ed.smith@collabora.com>
This is a separate commit because it significantly improves git's ability to reason about the rename. Signed-off-by: Ed Smith <ed.smith@collabora.com>
The new LavaMock provides much more functionality than the previous one (which is now called Server). It encapsulates four key objects for creating test simply, as well as a simplified interface for creating jobs and devices: - The Server that provides the data. - The SharedState which holds the mock data. - The Clock which the mock object uses. - A set of Generator instances to create new objects. Signed-off-by: Ed Smith <ed.smith@collabora.com>
This shortens and simplifies many of the tests. Signed-off-by: Ed Smith <ed.smith@collabora.com>
eds-collabora
force-pushed
the
eds/porcelain
branch
from
e0a03b7 to
d99575f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a draft from the former location of
lava-api; it's been parked for a long time, and may need some freshening up. There may be unaddressed feedback from previous iterations of this PR at present.The old MR description is below, and is likely in need of cleanup.
This contains essentially one reworked full-size test, in
lava-api/src/job.rs (test_basic), plus a much smaller, specific test
in test_basic_porcelain.
The porcelain object itself is another layer on top of the lava
mock. It incorporates a SimClock, which is often what you want for
reliable, sensible testing of time behaviour (where the time is
whatever you say it is).
The main inelegancies here:
The proxy interface is optional until it isn't: there's no
disguising that once you got hold of an object, it contains proxies.
There's very limited customisation, and it bridges poorly with other
ways of constructing more customised options. It effectively
functions as a simplified mode, with no clean escapes to "advanced"
mode.
Because you do not have a context for accessing data in the shared
state, you always have to poke whatever you want to poke from within
a lambda.
The job interface is incomplete; the idea is to be able to push a job
along as desired just by calling the lifecycle methods on the
porcelain object.
Two sets of generators are maintained. The first generators are used
when calling add_job and friends, to populate the vast majority of the
fields in the job object itself. The second bank of generators (bulk_)
are used when generating large numbers of items at once. In this case,
there are no available fields from the user at all, so the generator
needs to fill in additional data (and filling in that data can have
side effects, which is why we don't fill in and overwrite).