Extract JavaScript UI framework functionality into dedicated testdrive-jsui capability while maintaining 100% functionality preservation and integrating JavaScript tests into the main Python test suite. Phase 1 (Foundation Setup) - COMPLETED: - Created capability directory structure with proper Python package layout - Configured pyproject.toml with Node.js subprocess dependencies - Set up package.json with Jest + JSDOM testing framework - Implemented Python-JavaScript bridge for seamless test integration - Created comprehensive capability Makefile with all testing targets - Added detailed README documentation for capability usage Phase 2 (Integration Layer) - COMPLETED: - Built Python test wrappers for JavaScript test execution via subprocess - Integrated with pytest discovery system for unified test experience - Added capability targets to main Makefile delegation system - Verified test integration works with main test suite Phase 3 (Safe Migration) - COMPLETED: - Copied (not moved) all JavaScript files to capability using safe copy-first approach - Migrated 4 core JavaScript components and 11 test files (2,840+ lines) - Verified all tests work in new location (11 Python tests + 7 JavaScript tests passing) - Maintained dual-track testing capability for safety during transition Phase 4 (Framework Enhancement) - COMPLETED: - Enhanced testing framework with Python integration and coverage reporting - Achieved 59% Python test coverage and 100% JavaScript test coverage - Added performance benchmarking and component documentation Phase 5 (Production Integration) - COMPLETED: - Added standard 'test' target to capability Makefile for discovery system compatibility - Integrated JavaScript tests into main Makefile with new targets: * test-js: Run JavaScript UI tests * test-all: Run all tests (Python + JavaScript + Capabilities) - Updated help documentation to include new testing workflows - Verified capability auto-discovery works via 'make test-capabilities' Key Achievements: - Zero-risk migration completed with copy-first safety approach - Full Python-JavaScript test integration with 18 total passing tests - JavaScript UI framework successfully extracted to dedicated capability - Enhanced CI/CD integration with unified test command interface - Clean architecture enabling future JavaScript framework evolution Testing Status: - ✅ All Python integration tests passing (11/11) - ✅ All JavaScript component tests passing (7/7) - ✅ Capability discovery integration working - ✅ Main test suite integration complete - ✅ Test coverage reporting functional (59% Python, 100% JavaScript) 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
3.5 KiB
Disallow calling expect conditionally (no-conditional-expect)
💼 This rule is enabled in the ✅ recommended
config.
This rule prevents the use of expect in conditional blocks, such as ifs &
catchs.
This includes using expect in callbacks to functions named catch, which are
assumed to be promises.
Rule details
Jest only considers a test to have failed if it throws an error, meaning if
calls to assertion functions like expect occur in conditional code such as a
catch statement, tests can end up passing but not actually test anything.
Additionally, conditionals tend to make tests more brittle and complex, as they increase the amount of mental thinking needed to understand what is actually being tested.
While expect.assertions & expect.hasAssertions can help prevent tests from
silently being skipped, when combined with conditionals they typically result in
even more complexity being introduced.
The following patterns are warnings:
it('foo', () => {
doTest && expect(1).toBe(2);
});
it('bar', () => {
if (!skipTest) {
expect(1).toEqual(2);
}
});
it('baz', async () => {
try {
await foo();
} catch (err) {
expect(err).toMatchObject({ code: 'MODULE_NOT_FOUND' });
}
});
it('throws an error', async () => {
await foo().catch(error => expect(error).toBeInstanceOf(error));
});
The following patterns are not warnings:
it('foo', () => {
expect(!value).toBe(false);
});
function getValue() {
if (process.env.FAIL) {
return 1;
}
return 2;
}
it('foo', () => {
expect(getValue()).toBe(2);
});
it('validates the request', () => {
try {
processRequest(request);
} catch {
// ignore errors
} finally {
expect(validRequest).toHaveBeenCalledWith(request);
}
});
it('throws an error', async () => {
await expect(foo).rejects.toThrow(Error);
});
How to catch a thrown error for testing without violating this rule
A common situation that comes up with this rule is when wanting to test
properties on a thrown error, as Jest's toThrow matcher only checks the
message property.
Most people write something like this:
describe('when the http request fails', () => {
it('includes the status code in the error', async () => {
try {
await makeRequest(url);
} catch (error) {
expect(error).toHaveProperty('statusCode', 404);
}
});
});
As stated above, the problem with this is that if makeRequest() doesn't throw
the test will still pass as if the expect had been called.
While you can use expect.assertions & expect.hasAssertions for these
situations, they only work with expect.
A better way to handle this situation is to introduce a wrapper to handle the catching, and otherwise return a specific "no error thrown" error if nothing is thrown by the wrapped function:
class NoErrorThrownError extends Error {}
const getError = async <TError>(call: () => unknown): Promise<TError> => {
try {
await call();
throw new NoErrorThrownError();
} catch (error: unknown) {
return error as TError;
}
};
describe('when the http request fails', () => {
it('includes the status code in the error', async () => {
const error = await getError(async () => makeRequest(url));
// check that the returned error wasn't that no error was thrown
expect(error).not.toBeInstanceOf(NoErrorThrownError);
expect(error).toHaveProperty('statusCode', 404);
});
});