Report setUp()/tearDown() overrides that don't call the parent

Open
  • Is something wrong?
#179 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@alies-dev is already working on this.

Since Nov 9, 2026.

  • #215 by @alies-dev — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
php
Domain
testing

Research direction

Read the issue's example and the linked ShouldCallParentMethodsRule in phpstan-phpunit, then locate the plugin's afterClassLikeAnalysis handlers and their tests. Add coverage for the four lifecycle methods, including overrides of non-TestCase declarations and missing top-level parent calls. Done means the plugin reports the missing call and its tests cover the stated cases; an open pull request is already linked.

Written by the indexing model from the issue text.

Description

enhancement

When a test case extends a base test case that has its own setUp()/tearDown(), forgetting parent::setUp() silently skips the base fixture:

abstract class DatabaseTestCase extends TestCase
{
    protected function setUp(): void { $this->connection = Connection::open(); }
}

final class InvoiceRepositoryTest extends DatabaseTestCase
{
    protected function setUp(): void
    {
        $this->repository = new InvoiceRepository($this->connection); // parent::setUp() missing
    }
}

phpstan-phpunit reports this (ShouldCallParentMethodsRule). The rule only applies when the overridden method is not TestCase's own empty one.

Idea: in afterClassLikeAnalysis, for setUp, tearDown, setUpBeforeClass and tearDownAfterClass overriding a non-TestCase declaration, look for a top-level parent::<method>() call and emit a plugin issue otherwise. Roughly 60 lines with tests.

Idea borrowed from phpstan/phpstan-phpunit.

Dominant language
Gherkin
Stars
79
Forks
38
Avg merge
6h 52m
Merged PRs (30d)
28

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from psalm/psalm-plugin-phpunit

All issues in psalm/psalm-plugin-phpunit

Similar issues

More Testing & QA issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.