"nuxt start-dev" or similar for integration testing

[pedantic-git]

What problem does this feature solve?

I'm building a full-stack PWA which has full-stack integration tests. Currently in those integration tests, Nuxt is running in full 'dev' mode which means the following:

1. It has to rebuild the entire application when it starts up, which with Vuetify can take ages
2. It is running the webpack-dev-server, which is completely unnecessary for integration tests

An alternative would be to run nuxt build before starting the tests and then nuxt start for testing the app. The problems are:

1. nuxt start forces the dev flag to false, meaning that the app cannot run without ssl if the redirect-ssl middleware is installed (for example)
2. nuxt build hardcodes the values of environment variables at the time the app was built, which in my case will be before I know what API_URL (for @nuxtjs/axios should be)

What does the proposed changes look like?

A new command nuxt start-dev or nuxt start-test that is the same as nuxt start except:

1. The dev flag is set to true, and
2. (if possible) it respects changes to environment variables made after the build. I don't understand the build system fully for Nuxt so I appreciate this second option might not be possible.

What do you think? If you like the idea, let me know how I can help!

_{This feature request is available on Nuxt community (#c9205)}

[pi0]

Hi. You can set an env variable during build like this:

{
  env: {
    STAGE: process.env.STAGE
  }
}

And then align runtime behavior according to it. Like disabling redirects.

[pedantic-git]

Hi @pi0 - thanks for the workaround... I will certainly take a look.

I believe my case is a common enough use case that it might warrant a deeper look, however.

[pi0]

For integration testing, I believe it is best practice to keep it consistent and as much as possible near to production environment. Even something like HTTPS should be testable (something may be broken only via https protocol)

The dev: true condition is used for many community modules to consider we are in real development mode with webpack middleware, etc so it can easily break some of them.

[pedantic-git]

OK - thanks for the explanation. Instead, then, (assuming I want to continue testing in dev mode) would it be possible to create a version of nuxt dev that runs a pre-built copy of the application? My main concern is the large boot time during compilation in the middle of a test.

[pi0]

@pedantic-git I can probably help better if have an example when you need dev flag? (inside plugin, module, config, or...?)

---

A preview of what happens if we combine build + dev would be like this: (not tested or recommended! use with caution! :D)

modules/dev.js:

module.exports = function() {
  if (!this.options.dev && process.argv.find(a => a === '--dev')) {
    this.options.dev = true
  }
} 

And register in nuxt.config.js:

export default {
  modules: [
    '~/modules/dev.js'
  ]
}

Then when running yarn build --dev or yarn start --dev the dev flag will be set to true.

[pedantic-git]

I think it's perhaps just a misalignment of what I mean by 'integration test'.

My Rails app that provides the API is running in 'test' mode, which can be configured separately from dev and production, and I would ideally like the Nuxt app that runs alongside it to be configured in the same way.

For example, I know I don't care about SSL, so I would like the redirect-ssl module to do its normal thing of ignoring its behaviour in test mode.

But Capybara (a Ruby web browser for tests) starts the Rails app on a custom port so there's not really any way to start Nuxt until after the tests begin executing, and it only gives 60 seconds for any servers to start up, which is sometimes not long enough to start Nuxt.

In my mind, the solution to this was to separate the build and start steps for this 'test mode' Nuxt so that we're not waiting for the compilation during application startup, but you may have an alternative idea!

I believe this is (or should be) quite a common use case for a Nuxt app with a backend written in another language/framework.

Your workaround above might well be what I need for now, but I'd like to explore the possibility of something more "official"?

[pi0]

@pedantic-git Can add a CI step before tests to do nuxt build? nuxt start itself should take few seconds.

How do you register redirect-ssl middleware? We can easily use an environment variable to disable it. Actually, anything is bundled needs a rebuild in order env changes taking effect but all node.js related parts can be changed even after build using env.

[pedantic-git]

@pi0 It's registered like this:

  serverMiddleware: [
    'redirect-ssl'
  ],

I can't readily find the docs to conditionally disable it using an env.

The other envs that are an issue are API_URL / API_URL_BROWSER (from @nuxtjs/axios) which will change depending on the run env. If they can only be set during the build it's probably OK for me to rewrite the backend test so it always runs on the same port instead of a random one.

[pedantic-git]

(PS. Thank you so much for your help and understanding so far! Once this is done I promise I'll write it up in some form for others to take advantage of.)

[jay8t6]

@pi0 question, if I run nuxt start for integration testing on a bitbucket pipeline, it just hangs, I was wondering if there is a way to run nuxt start in quiet mode so I can use cypress to do the e2e testing.

[abarkhurst]

@pi0 question, if I run nuxt start for integration testing on a bitbucket pipeline, it just hangs, I was wondering if there is a way to run nuxt start in quiet mode so I can use cypress to do the e2e testing.

@jay8t6 were you able to find a solution for this?

[basuneko]

To anyone who stumbles on this, when running nuxt start on CI it doesn't print anything so it looks like it hangs indefinitely. But the server does work and accepts connections.
It took me a few hours to figure that out.