push-based / user-flow

📦 Combine Chrome tooling like Lighthouse userflows and DevTools reconder scripts in your CI
MIT License
118 stars 3 forks source link

Removing Cyclical Dependencies In User-Flow Tests #249

Closed ChristopherPHolder closed 1 year ago

ChristopherPHolder commented 1 year ago

Removing Cyclical Dependencies In User-Flow

Current State:

image

There are to sources of cyclical dependencies in user-flow both of which are related to testing

Cyclical Dependencies between the cli and user-flow-cli-testing

What is user-flow-cli-testing?

It is a testing utils lib that is used to facilitate the testing of certain parts of the cli.

Usage

This library seems to be imported in 3 other libraries

cli

  1. packages/cli/src/lib/commands/collect/utils/persist/persist-flow.test.ts
  1. packages/cli/src/lib/commands/collect/utils/user-flow/load-flow.test.ts
  1. packages/cli/src/lib/commands/init/processes/generate-userflow.test.ts
  1. packages/cli/src/lib/global/cli-mode/cli.mode.test.ts
  1. packages/cli/src/lib/pre-set.test.ts

sandbox

  1. packages/sandbox/e2e/cli/configuration.test.ts
  1. packages/sandbox/e2e/commands/collect/collect-configuration.test.ts
  1. packages/sandbox/e2e/commands/collect/collect.budgets.test.ts
  1. packages/sandbox/e2e/commands/collect/collect.config.test.ts
  1. packages/sandbox/e2e/commands/collect/collect.dry-run.test.ts
  1. packages/sandbox/e2e/commands/collect/collect.format.test.ts
  1. packages/sandbox/e2e/commands/collect/collect.ufPath.test.ts
  1. packages/sandbox/e2e/commands/init/init-configuration.test.ts
  1. packages/sandbox/e2e/commands/init/init.test.ts
  1. packages/sandbox/e2e/commands/init/rc-config.test.ts
  1. packages/sandbox/e2e/jest/expect.collect.budget.ts
  1. packages/sandbox/e2e/jest/expect.collect.format.ts
  1. packages/sandbox/e2e/jest/expect.collect.ts
  1. packages/sandbox/e2e/jest/expect.ts

test-data

  1. packages/test-data/src/lib/config/lh-config.ts
  1. packages/test-data/src/lib/sandboxes/empty/cfg.ts
  1. packages/test-data/src/lib/sandboxes/initialized/cfg.ts
  1. packages/test-data/src/lib/sandboxes/remote/cfg.ts
  1. packages/test-data/src/lib/sandboxes/remote/rc.ts
  1. packages/test-data/src/lib/sandboxes/static/cfg.ts
  1. packages/test-data/src/lib/sandboxes/static/rc.ts
  1. packages/test-data/src/lib/sandboxes/user-flowrc.base.ts

Concat and sorted list of imports

'Test Helper Classes'

'Test Helper Functions'

'Test Helper Type'

'Internal Type'

'External Lib Type'

'Dynamic Values'

'CONSTANT_VALUES'

Suggested solution

All values values identified as 'CONSTANT_VALUES' can be moved to a lib called seed data. This lib cannot depend on any internal lib as it should only contain defaults. If the constant value is used in multiple libraries it should be moved to this lib. Values that should not be located here are those who are only used as test data, and those can be placed in test-data. Optional: Seed data has no internal dependencies. If a type is required it should be type-cased externally when it is used. If a value will require being used with typecasting a comment can be made with the value.

The data named as a const but that requires being modified to be used in different environments should be modified at its final destination. If necessary we can have a helper that takes a constant value and modifies it after being given an argument. The const should be moved to seed-data and a helper should be implemented in the test that modifies it there.

I am aware of the fact that this makes things a lot less readable, however if the cli testing utils is going to be used inside of cli it cannot import anything from cli. However, the benefit is that simply by insuring that it does not require the importing from the cli itself it will make the tool useful for any other projects consuming the cli helper

As this will now become a generic tool it can be renamed to reflect the fact.

Assertions

ChristopherPHolder commented 1 year ago

Creating proper module boundaries would help prevent this in the future.