Default Test

Description of the Problem

The Default Test refers to tests that are automatically generated by frameworks or project templates and remain in the codebase without being adapted to the real business logic of the application. These tests are usually created as example, smoke, or starter tests and are not intended to represent meaningful validation of system behavior.

In Flutter projects, the most common example is the default counter smoke test generated when a new application is created. Although this test executes successfully and validates a basic UI interaction, it does not reflect any domain-specific requirement, business rule, or real usage scenario of the system.

As a result, a Default Test may give the impression that the application is properly tested, while in reality it only verifies the behavior of template code that is often removed or heavily modified early in development.

Symptoms and Impact

  • False Sense of Test Coverage Default tests often pass consistently, giving the impression that the application is well tested, even though no real functionality is being validated.

  • Lack of Business Value These tests do not validate domain rules, edge cases, or critical behaviors required by the system.

  • Test Suite Pollution Keeping template-generated tests increases the size of the test suite without increasing confidence in the system, making maintenance harder over time.

  • Misleading Quality Indicators Metrics such as code coverage or number of tests may appear healthy while providing little real assurance.

Identification Criteria

A Default Test can be identified by the following characteristics:

  • The test is generated automatically by a framework or project template.
  • The test validates example or placeholder functionality (e.g., counters, sample widgets).
  • The test has not been adapted to reflect real application requirements.
  • The test name and structure closely match the default template provided by the framework.

Code Example

Example of a Default Test (Flutter Template Test)

import 'package:flutter_test/flutter_test.dart';
import 'package:flutter/material.dart';
import 'package:myapp/main.dart';

void main() {
  testWidgets('Counter increments smoke test', (WidgetTester tester) async {
    // Build the app and trigger a frame.
    await tester.pumpWidget(const MyApp());

    // Verify that the counter starts at 0.
    expect(find.text('0'), findsOneWidget);
    expect(find.text('1'), findsNothing);

    // Tap the '+' icon and trigger a frame.
    await tester.tap(find.byIcon(Icons.add));
    await tester.pump();

    // Verify that the counter has incremented.
    expect(find.text('0'), findsNothing);
    expect(find.text('1'), findsOneWidget);
  });
}

Why this is a Default Test:

  • It tests a template counter widget, not real application logic.
  • It exists primarily as an example provided by Flutter.
  • It does not validate any domain rule or business requirement.
  • In most real applications, the counter widget is removed or irrelevant.

Example Without Default Test

import 'package:flutter_test/flutter_test.dart';
import 'package:myapp/features/auth/login_view.dart';

void main() {
  testWidgets('Displays error message when login fails', (WidgetTester tester) async {
    await tester.pumpWidget(const LoginView());

    await tester.enterText(find.byKey(const Key('emailField')), 'user@test.com');
    await tester.enterText(find.byKey(const Key('passwordField')), 'wrong-password');
    await tester.tap(find.byKey(const Key('loginButton')));
    await tester.pump();

    expect(find.text('Invalid credentials'), findsOneWidget);
  });
}

This test:

  • Reflects a real feature of the application.
  • Validates a business-relevant scenario.
  • Increases confidence in system behavior.

Suggested Refactorings

To address the Default Test smell:

  • Remove Template Tests Delete default tests that no longer represent the application’s behavior.

  • Adapt Instead of Keeping If the structure is useful, refactor the test to validate real features instead of example logic.

  • Focus on Business Behavior Ensure that every test validates a requirement, rule, or critical scenario.

  • Review Tests After Project Initialization Default tests should be reviewed and either removed or rewritten as soon as development begins.

Exceptions and Special Cases

A Default Test may be acceptable temporarily:

  • As a sanity check during the first project setup.
  • For learning or onboarding purposes.
  • When used intentionally as a minimal smoke test in very early stages.

Even in these cases, the test should be removed or replaced as soon as real functionality is implemented.

References

  • Fowler, M. (1999). Refactoring: Improving the Design of Existing Code
  • Meszaros, G. (2007). xUnit Test Patterns: Refactoring Test Code
  • Flutter Documentation. Testing Flutter Apps

Note

The Default Test is not inherently wrong, but it becomes a test smell when it remains in the codebase without serving a meaningful validation purpose. High-quality test suites prioritize behavioral relevance over quantity, ensuring that each test contributes real confidence to the system.