add tests for develop and serve commands about greenwood

[hutchgrant]

My thinking is we should be able to test that a page is visible at a host and port for the dev server. Also perhaps we could test results of live-reload by modifying a page md file?

Potential problems are validating when the dev server has compiled and is up before testing it.

I think we could simply use puppeteer to waitFor(someElement) then check elements on page after live-reloading an update to the md file.

[hutchgrant]

In that case, we can only test the scaffolding to make sure everything was prepared properly pre-webpack. Which would mean we'd have to read and parse js files to make sure everything is there. Not sure how to go about that.

At least with the webpack-dev-server running we could test everything compiled. Surely there's a way to end the process.

[thescientist13]

Yeah, I was thinking just testing everything up until webpackDevServer, after that, as we'd just be unit testing webpackDevServer at that point, which isn't as valuable.

Also, I'm not so worried about hitting a live set, but rather just running greenwood develop without running the dev server, which is a process that needs to be ended, or else the tests won't finish.

[thescientist13]

which would mean we'd have to read and parse js files to make sure everything is there. Not sure how to go about that.

our prod tests are pretty much doing that already though right? So instead of doing it post compilation, we would just be doing it pre compilation. I suppose one could argue that if the prod task was broken, then develop task would obviously be broken, but capturing the cases independently is probably still worth it, even if there is a little overlap.

better safe than sorry. ☝️

[thescientist13]

So taking a stab at this. However, noticing that when running yarn develop

Initializing project workspace contexts
Generating graph of workspace files...
Scaffolding out project files...
Generate pages from templates...
Writing imports for md...
Writing Lit routes...
setup index page and html
Scaffolding complete.
Starting local development server
(node:14161) DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead
ℹ ｢wdm｣: Hash: 0b9cce5447497d21ef65

That Tapabler.plugin warning seems to be getting picked up by the runner

  Develop Greenwood With:
    Default Greenwood Configuration and Workspace
      1) "before all" hook for "should test webpack dev server started"


  0 passing (2s)
  1 failing

  1) Develop Greenwood With:
       Default Greenwood Configuration and Workspace
         "before all" hook for "should test webpack dev server started":
     Error: the string "(node:14191) DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead\n" was thrown, throw an Error :)

So that might present its own hurdle to testing this task. Will see if upgrading some webpack dependencies helps, but not sure which plugin or loader specifically is complaining.

edit: narrowed it down to FileWatcherPlugin. Raised an issue in their repo.
sap9433/filewatcher-webpack-plugin#13

Not sure if it's actively maintained though. This repo was provided as an alternative while looking through their issue tracker
https://github.com/Fridus/webpack-watch-files-plugin

[thescientist13]

Should try and expand coverage as much as possible to at least get everything within the thresholds.

[thescientist13]

So although we've moved away from webpack, the challenges presented still apply in trying to do the testing in that starting a server will hang the node / mocha process. Luckily I have added support for this workflow in thescientist13/gallinago#19 !

So now we can test a server and make sure command specific behaviors actually work as expected, like

• import maps
• live reload
• etc

[thescientist13]

Made some good progress in #670 , but still a couple TODOs so going to leave this open to put into the next project to try and tack another crack at the server command + mode specs that I would like to add (and GraphQL client!)
#670 (comment)

[thescientist13]

Also make sure to better handle 404 routes from develop, as per the test logs you'll see this

Develop command with default 404 behavior
(node:17870) UnhandledPromiseRejectionWarning:
  Error: ENOENT: no such file or directory, open '/abc.js'


(Use `node --trace-warnings ...` to show where the warning was created)
(node:17870) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:17870) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Probably want to make some 404 handler resource plugin that can go at the end of all the other plugins and if there is a 404 status code, do something like return Not Found or something.

Or as part of #240 (comment) ?

[thescientist13]

leaving remaining E2E testing coverage to this discussion as I think we've squeezed as much as we can out of mocha, and our coverage is really good!