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
Add documention clarifying use of scenarios (#1427) #1802
Add documention clarifying use of scenarios (#1427) #1802
Conversation
That said, you can still configure your default scenario file to honor options passed | ||
to the runtime environment. For example, if you created a scenario file called `some-scenario.js` | ||
and wanted to load that scenario based on an environment variable called `MIRAGE_SCENARIO`, you | ||
could add the following to `scenarios/default.js`: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requested changes for first three paragraphs: generalize the motivation a bit (not just user acceptance testing), and open with the bit about not being a first-class API. Something like:
Mirage adds a
/scenarios
directory to your project, where you'll find adefault.js
file. The function in this file will run in development mode and act as your "development seeds". In testing it's ignored, so that your Mirage server starts out with a clean database. You can then use each test to seed Mirage as needed for that test. In this way, each test acts as its own Mirage scenario.
Originally Mirage was going to add first-class support for development-time scenario switching, but right only the the
scenarios/default.js
file is used by Mirage. However, you can use various strategies to configure the behavior of your default scenario, to support multiple development server states or to facilitate things like running user acceptance testing. For example, you might want to test whether a user can complete a set of tasks specific to unique circumstances defined in a scenario.
One strategy you could take is to configure your default scenario file to honor options passed to the runtime environment. For example...
Finally, you could switch between scenario files on the command line: | ||
|
||
```bash | ||
MIRAGE_SCENARIO=some-scenario ember s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's move this part first, so as we're explaining the reader knows the starting point. Let's also avoid the private server._config
.
One strategy would be to use ENV vars to switch scenarios. For example, say you wanted to be able to run a scenario file like this:
MIRAGE_SCENARIO=administrator ember s
To use this MIRAGE_SCENARIO
ENV variable to alter the behavior of scenarios/default.js
, add it to your environment/config.js
:
const { MIRAGE_SCENARIO } = process.env;
module.exports = function(environment) {
const ENV = {
// ...other stuff
MIRAGE_SCENARIO,
// ...other stuff
};
return ENV;
}
then access this new config variable in your scenarios/default.js
file:
// scenarios/default.js
import ENV from '../../config/environment';
import visitor from './visitor';
import subscriber from './subscriber';
import administrator from './administrator';
const scenarios = {
visitor,
subscriber,
administrator
}
const activeScenario = ENV.MIRAGE_SCENARIO || 'visitor';
export default function(server) {
const scenario = scenarios[activeScenario];
if (scenario) {
scenario(server);
}
// plus whatever default scenario code you want
}
Nice work, added some comments! |
@samselikoff thank you for the thorough feedback! Really appreciate it. Will take a look and address. |
238fb3f
to
4f07a09
Compare
@samselikoff pushed more changes. Please let me know if I can improve anything else. |
4f07a09
to
9849931
Compare
Looks great – thank you Matt! |
This PR adds some documentation about scenarios and ways to use them more effectively.