You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we leave it to the user to use the test runner they already have for running the shutter tests.
The downside is that the resulting test code does usually does not look 100% smooth and requires us to document usage of shutter with any major test runner.
An alternative might be to add some really basic test runner functionality to the shutter CLI.
It might sound like re-inventing the wheel at first, but it does make some sense, because the use case and they kind of test you write for shutter is rather different to unit and integration test code.
// shutter.config.json5 or as "shutter" property in package.json{files: {'/styles.css': 'build/styles.css'},head: [<linkrel='stylesheet'href='/styles.css'/>]}
Running the tests:
$ npx shutter test
Zero config:
The test runner will check if there is a babel config or tsconfig.json and load @babel/register, babel-core or ts-node, so cutting edge code and JSX will work without further ado.
Still unsolved
What about webpack setups with custom loaders (CSS modules or worker loader, for instance)?!
To be fair, that's an issue as of now, anyway...
The text was updated successfully, but these errors were encountered:
The export default object is rather hard to read. This might be more intuitive to use:
import{configure,snapshot,test}from'@shutter/react'importThemeProviderfrom'../theme/provider'constThemeAProvider=({ children })=>(<ThemeProvidertheme='A'>{children}</ThemeProvider>)// Config object could also passed to `component()` or `snapshot()` as additional parameterconfigure({decorate: ThemeAProvider})test('Button',[snapshot('default',<Button>Click me</Button>),snapshot('primary',<Buttonprimary>Click me</Button>)])
Edit: Changed component() to test() as you can use the core package to test whole static pages, not only components.
Right now we leave it to the user to use the test runner they already have for running the shutter tests.
The downside is that the resulting test code does usually does not look 100% smooth and requires us to document usage of shutter with any major test runner.
An alternative might be to add some really basic test runner functionality to the
shutter
CLI.It might sound like re-inventing the wheel at first, but it does make some sense, because the use case and they kind of test you write for shutter is rather different to unit and integration test code.
How it could look like
Running the tests:
$ npx shutter test
Zero config:
The test runner will check if there is a babel config or
tsconfig.json
and load@babel/register
,babel-core
orts-node
, so cutting edge code and JSX will work without further ado.Still unsolved
What about webpack setups with custom loaders (CSS modules or worker loader, for instance)?!
To be fair, that's an issue as of now, anyway...
The text was updated successfully, but these errors were encountered: