如何在JMockit中定义通用Expectations类并在测试用例中扩展重写？

Absolutely! Creating a reusable base Expectations class is a fantastic way to cut down on repetitive code in your JMockit tests—this is a tried-and-true pattern that keeps test suites clean and maintainable. You can absolutely define a common base class with shared mock setups, then extend or override it in individual test cases as needed.

Here's how to implement this effectively:

1. Build Your Base Expectations Class #

First, create a base class that extends JMockit's Expectations and includes all the common mock behavior your tests share. Put this logic in the constructor so it runs automatically when any subclass is instantiated:

public class BaseTestExpectations extends Expectations {
    public BaseTestExpectations() {
        // Example: Mock a shared utility class with default behavior
        new MockUp<SharedConfigUtility>() {
            @Mock
            public String getAppConfig(String key) {
                // Default test config value for all tests
                return "test-environment";
            }
        };

        // Add other universal mocks, like logging services or database connectors
        new MockUp<LoggingService>() {
            @Mock
            public void logInfo(String message) {
                // No-op or default logging behavior for tests
            }
        };
    }
}

2. Extend and Customize in Test Cases #

In your individual test methods, instantiate an anonymous subclass of your base class. You can add test-specific expectations or override the default behavior from the base class directly in the initializer block:

@Test
public void testUserRegistrationWithCustomConfig() {
    new BaseTestExpectations() {
        {
            // Override the default config value for this specific test
            new MockUp<SharedConfigUtility>() {
                @Mock
                public String getAppConfig(String key) {
                    if ("registration.enabled".equals(key)) {
                        return "true";
                    }
                    // Fall back to base class behavior for other keys
                    return super.getAppConfig(key);
                }
            };

            // Add a test-specific mock for the user repository
            new MockUp<UserRepository>() {
                @Mock
                public boolean saveUser(User user) {
                    return user.getEmail().contains("@test.com");
                }
            };
        }
    };

    // Execute your test logic
    UserService userService = new UserService();
    boolean result = userService.registerUser(new User("john@test.com"));
    
    // Assertions
    assertTrue(result);
}

Key Notes on Overriding #

JMockit processes MockUp instances in the order they're created. Since your test-specific mocks are defined after the base class ones, they'll take precedence—so any overridden methods in the test will replace the base class's default behavior.

3. Pro Tips for Maintainability #

• Keep the base class lean: Only include mock logic that's used across most of your tests. Avoid adding test-specific code here, as it will bloat the class and reduce its reusability.
• Use helper methods: If you have complex shared setup logic (like initializing a mock database with test data), extract it into protected methods in the base class. Tests can call these methods when needed instead of duplicating code.
• Document the base class: Add comments explaining what each mock in the base class does—this helps other testers understand the default behavior without digging through every test.

内容的提问来源于stack exchange，提问作者Daniel Yoon