refs https://github.com/TryGhost/Toolbox/issues/169
- Before releasing Ghost v5 we would like to move all canary-related URLs to a non-versioned format, which will become a default in v5.
- 'canary' is by definition unstable, so breaking any unprepared client explicitly using the canary is expected
- Removed the aliased /content/ and /admin/ apps from app.js because with updated configuration they become duplicates of 'canary' endpoints
refs f48892028d
refs 33da584161
- There was another mather added recently: anyDateWithTimezoneOffset. The naming of date-related matchers was getting long and confusing. Renamed existing date matcher to better reflect what they do and they types of matches they are responsible for, following renames have been done:
- anyShortDate -> anyISODate
- anyDate -> anyISODateTime
- anyDateWithTimezoneOffset -> anyISODateTimeWithTZ
refs https://github.com/TryGhost/Toolbox/issues/215
- The ContentAPI needs it's own test agent, so we can write e2e tests.
- The main method mostly to be used by the test suites is "authenticate" - it add necessary authentication keys to the request. The agent is not authenticated by default because there are suites that need to test the "non authenticated" requests. Also, there's a need to have the default API key inserted from fixtures level before authenticating (it's not strictly necessary because the key is not dynamic, but I think coupling this point would be a bad move)
refs https://github.com/TryGhost/Toolbox/issues/215
- Ghost tests had difficulty running sometimes when the versions for jest-snapshot package did not match in Ghost and @tryghost/express-test
- This is the error that was showing up: `IncorrectUsageError: Unable to run snapshot tests, current test was not configured`
- The reason why snapshot tests were misconfigured was multiple instances of SnapshotManager, which broke the singleton pattern
- Having jest-snapshot embeded within express-test makes sure the versions stay the same across the clients
- The version bump also introduces passing "queryParams" parameter into the Agent constructor - enables configuring query parameters that would appear in each agent's request. Example usecase - Content API authentication parameter "key" would be nice to "remember" and add to every request URL
refs https://github.com/TryGhost/Toolbox/issues/214
- TestAgent was used to initialize both Admin & Member API agents, which is somewhat confusing because Member API does not have the same "loginAs" functionality like Admin API does
- Having distinct agents for each API makes the class API cleaner with possibility to extract common functionality even further
no issue
- The test was failing because the match for a the data has changed, which was returned in a short format YYYY-MM-DD.
- Added a new matcher for short date format -anyShortDate. Can be used for match dynamic dates in short format
refs https://github.com/TryGhost/Toolbox/issues/214
- Calling `getMembersAPIAgent` and `getAdminAPIAgent` separately was booting Ghost twice, which caused a significant performance degradation.
- Additionally, having two calls was slightly ugly and having once utility function that delivers multiple agents at once feels like more readable syntax
- Often in our API we want to check that the location string looks roughly right for a resource
- At the moment we're matching any String, this upgrades the check to look for resource URLs
refs: https://github.com/Ghost/Ghost/commit/b5ee17b25
- When moving the site tests into e2e-api they broke because they were getting the changed settings value from the settings test
- The solution is to ensure the settingsCache is reset between tests, which is what this commit does
- This commit also renames the shutdown method to reset, because this is not a permanent operation
- It also renames the resetDb method to resetData, because the concept is we want the internal data to be reset, not just the DB
no-issue
Because we were returning the call to `boot`, rather than awaiting it,
it meant that once a test was provided with an API Agent the Ghost
application hadn't necessarily started. This was noticed whilst working
on the Members API which requires the frontend to be loaded.
When the frontend is loaded we must also wait for the url service to
have finished initialising, so that we do not run into 503 maintenance
errors when hitting the frontend.
no-issue
The Members API is served on a different endpoint to the Admin API, and
also requires that the frontend is booted. This agent is to be used when
testing the Members API, e.g. Stripe webhooks or Members config.
- The admin API test agent doesn't boot the Ghost frontend, which is where members routes are currently located
- This means we can't test members properly as we don't have access to webhooks etc
- This change adds a members option to getAdminAPIAgent(), which in turn enables the frontend
- We do it this way so that we can easily change the implementation later, e.g. if we have the option to boot members directly
- When starting ghost for e2e tests we create a content folder in the os tmp dir
- This means that the folder can change between suites as ghost is started and restarted
- For the most part this is fine, but theme storage caches the path to config (which makes sense, it's not meant to change whilst Ghost is in-memory)
- This is a quick-n-dirty fix that just makes it possible to update that path in the tests, so we know it's in sync
- Ideally we'd not cache the path, use a function to fetch it etc, or fully reset the theme storage layer, but this is the fix I have working today
and so it's going in to unblock things for now
- Can now easily mock labs flags as enabled or disabled using mockManager
- Updated some bits of code that directly mocked labs
- Aside: improved error thrown when things go wrong booting Ghost
refs: https://github.com/TryGhost/Toolbox/issues/158
- continuing to turn this into a reference test suite for how to do things with the new framework
- use fixtureManager and mockManager properly
- testUtils should _not_ be required anymore!
- TODO: cleanup labs mocking and side effect assertion using models
refs: https://github.com/TryGhost/Toolbox/issues/158
- rather than just exposing any, anything and string matching, expose more specific matchers.
- this was triggered by `any(Date)` not working for dates in our API
- it seems poor to match `any(String)` for something we want to be a well formatted date
- establishes the pattern of using our defined matchers instead of requiring any/anything from jest
refs: https://github.com/TryGhost/Toolbox/issues/158
- Working up to having these be the defacto "reference" tests
- Changing this allows for the fact that there will be a getContentAPIAgent, and probably more in future
- Abstracting away the path to a single location will make updating API paths easier later too
refs TryGhost/Toolbox#158
refs TryGhost/Toolbox#129 (comment)
We now have @tryghost/jest-snapshot - a suite of utilities for using snapshots with mocha, should, etc
The @tryghost/express-test lib also uses it to provide chained snapshot assertions
This library was created because all the existing implementations I could find, including the in use @ethanresnick/chai-jest-snapshot
didn't properly support property matching. @ethanresnick/chai-jest-snapshot supposedly supported it, but the implementation was incorrect
and frequently lead to false test passes.
This library also has (after some back and forth) path resolution so that snapshots can live in a local __snapshots__ folder
- encapsulated concerns within individual objects
- this will allow us to refactor these into classes or move them around later
- also makes it clearer how methods like restore relate to other methods
- e.g mocks.restore() restores mocks, whilst fixtureManager.restore() restores the database
- Ensure that the DB is always reset between tests
- We assume that the DB will be torn down and rebuilt between tests
- Without this, previous tests clobber the current tests, and it's not possible to tell when running files in isolation
which makes developing really tricky
refs https://github.com/TryGhost/Toolbox/issues/158
- To make the development quicker the copy-paste code was left in the codebase but gave immediate smell. Removed it to stop bothering me every time I look at the related code :)
refs https://github.com/TryGhost/Toolbox/issues/129
- The "Origin" header is require in Admin API requests so it makes sense to bake it into a default request made by most tests. Reduces unnecesary fluf around test request setup and removes a "config" dependency in each tests suite using the "e2e framework"
refs https://github.com/TryGhost/Toolbox/issues/158
- Moving common mocking/stubbing/spying logic into an outside utils module allows test suites to keep agnostic towards which framework powers mocking etc. Should also substitute email service stubbing used in multiple places
- Bonus, got rid of should dependency, which is deprecated
refs https://github.com/TryGhost/Toolbox/issues/129
- Adds content folder creation based on fixtures for e2e tests using the e2e framework
- Mostly a copy-paste for now from existing e2e utils with some simplifications, so we can "complicate things" later only if needed
refs 24505db918
- The code is heavily borrowed from the referenced commit by @ErisDS. It starts a fresh abstraction layer for all e2e tests to use, provides simle interface for request agent initialization and state management (read the e2e-framework top file description for more)
- Main methods the framework exposes are:
- getAgent - to initialize request agent with a fresh Ghost instance
- initFixtures - to initializer a fresh db state
- resetDb - cleans up the db state if there were state manipulations during the test suite run (POST, PUT requests or non-default fixtures)
refs https://github.com/TryGhost/Toolbox/issues/129
- Having a fresh module should allow building new testing utility concepts from the ground up without being tied by the mystery baggage of the legacy localUtils/testUtils
- The outline of the concepts the framework will be handling is in the commont on the top of the e2e-framework file
