Testing Strategy — Series 2

Preview — 3 of 10 questions

Every test of this class needs forty lines of setup. What is the most useful conclusion?

javascript

@Injectable()
export class CheckoutService {
  constructor(
    private readonly orders: OrdersService,
    private readonly payments: PaymentsService,
    private readonly inventory: InventoryService,
    private readonly mailer: MailerService,
    private readonly analytics: AnalyticsService,
    private readonly config: ConfigService,
    private readonly cache: CacheService,
  ) {}
}

AThe test module should use useMocker so the setup disappears

BThe tests should move to the e2e level, where a real application is built once

CSetup cost is inherent to integration-heavy classes and carries no design information

DDifficulty writing the test is feedback about the design, not about testing: a class needing seven collaborators is doing several jobs, and splitting it — an orchestrator plus focused services — reduces both the setup and the coupling that made it necessary

What comes first?

javascript

A 600-line service with no tests must be restructured.

ARefactor first, then write tests against the clearer structure

BCharacterisation tests: capture the current behaviour — including behaviour that looks wrong — so the refactor can be verified to change nothing, and any deliberate behaviour change is a separate, visible commit

CA rewrite from the specification, since the existing behaviour is unknown anyway

DFull branch coverage of the existing code before touching anything

What should the migration's test cover?

javascript

ALTER TABLE users ADD COLUMN full_name text NOT NULL DEFAULT '';
UPDATE users SET full_name = first_name || ' ' || last_name;

AThat the TypeScript compiles and the migration file is registered

BThat the schema after up() matches the entity definitions

CBoth directions against realistic data: up() transforms existing rows correctly — including the awkward ones, such as a NULL last name — and down() restores a state the previous application version can run against; timing it on a production-sized copy also reveals a lock that would be unacceptable in a deploy

DNothing: migrations are generated and reviewed, which is sufficient

Answer all 10 questions (7 more), see explanations for every answer, and track your score.