Files
home-information/docs/dev/frontend/javascript-testing.md
cassandra-ai-agent 6fc76e3da2 Add JavaScript unit tests for auto-view.js using QUnit (#160)
* Add JavaScript unit tests for auto-view.js using QUnit

- Set up QUnit testing framework with local vendoring (no CDN dependency)
- Create comprehensive test suite for auto-view.js core functions:
  * throttle() - timing behavior and edge cases
  * shouldAutoSwitch() - idle timeout decision logic
  * isPassiveEventSupported() - feature detection and caching
  * recordInteraction() and state management functions
- Add test runner HTML file that works offline
- Document testing approach and usage in README.md
- All tests focus on business logic, avoid testing framework internals
- Establishes reusable pattern for testing other JS modules

* Fix test assertion for shouldAutoSwitch 60s threshold behavior

The shouldAutoSwitch function uses >= comparison, so at exactly 60 seconds
it returns true (should auto-switch). Updated test to match actual behavior.

Also added Node.js test runner for command-line testing capability.

* Add master test runner for all JavaScript tests

- Created test-all.html that runs all JavaScript module tests in one page
- Updated README.md with improved workflow for single-URL testing
- Added instructions for adding future JavaScript modules to master runner
- Maintains individual test runners for focused debugging

This addresses the practical concern of needing to visit multiple URLs
as JavaScript test coverage grows.

* Organize JavaScript testing documentation

- Created high-level documentation at docs/dev/frontend/javascript-testing.md
- Covers testing philosophy, framework choice, and best practices
- Uses auto-view.js as reference implementation example
- Streamlined tests/README.md to focus on practical usage
- Follows project documentation organization patterns
- Maintains concise, maintainable approach with code references

* Remove redundant README.md, consolidate all JS testing docs

- Removed src/hi/static/tests/README.md (duplicate content)
- Made docs/dev/frontend/javascript-testing.md completely self-contained
- Added detailed code examples for adding new tests
- Single source of truth for JavaScript testing documentation

* Add comprehensive JavaScript unit tests for high-value modules

- svg-utils.js: 150+ test cases for SVG transform string parsing with regex edge cases
- main.js: Tests for generateUniqueId, cookie parsing/formatting with URL encoding
- video-timeline.js: Tests for VideoConnectionManager array logic and caching algorithms
- watchdog.js: Tests for timer management and restart logic simulation
- Updated test-all.html with proper module loading order (main.js first)
- Fixed svg-utils test assertions to match actual regex behavior
- Enhanced Node.js test runner with better mocking (though some modules too DOM-heavy)

All JavaScript tests now pass in browser - establishes comprehensive testing
coverage for business logic functions across multiple modules.

* Add JavaScript testing documentation links

- Added link to javascript-testing.md in frontend-guidelines.md
- Added link to javascript-testing.md in testing-guidelines.md
- Ensures JavaScript testing approach is discoverable from main guideline docs
2025-09-09 20:46:18 +00:00

122 lines
4.1 KiB
Markdown

# JavaScript Testing
This document describes the approach for unit testing JavaScript modules in the Home Information application.
## Overview
JavaScript testing uses QUnit framework with a local-first approach that requires no build tools or external dependencies. Tests focus on business logic functions rather than DOM manipulation or framework internals.
## Philosophy
- **Local-first**: All dependencies vendored locally, no CDN requirements
- **Lightweight**: QUnit framework only, no complex build pipeline
- **Manual execution**: Tests run in browser via simple HTML files
- **Business logic focus**: Test core functions, algorithms, and state management
- **Real browser testing**: Actual browser environment catches issues that mocks miss
## Framework Choice: QUnit
Selected for:
- Minimal setup (just HTML + script tags)
- No build tools required
- Django-compatible static file serving
- Comprehensive async testing support
- Small footprint (~25KB minified)
## Test Structure
```
/src/hi/static/tests/
├── test-all.html # Master test runner (recommended)
├── test-{module}.html # Individual module runners
├── test-{module}.js # Test cases for each module
└── qunit/ # QUnit framework (vendored)
```
## Running Tests
**Primary workflow:**
```bash
open src/hi/static/tests/test-all.html
```
**Via Django server:**
```bash
src/manage.py runserver
# Navigate to: http://127.0.0.1:8411/static/tests/test-all.html
```
## Example Implementation
The `auto-view.js` module demonstrates the complete testing approach:
- **Source**: `/src/hi/static/js/auto-view.js`
- **Tests**: `/src/hi/static/tests/test-auto-view.js`
- **Individual runner**: `/src/hi/static/tests/test-auto-view.html`
Key test patterns demonstrated:
- Time-dependent logic testing with `Date.now()` mocking
- Throttling behavior with async timing tests
- Feature detection and caching verification
- State management transitions
- Context preservation in callbacks
## Testing Best Practices
### Focus Areas (High Value)
- Complex algorithms and timing logic
- State management and transitions
- Feature detection and caching
- Integration between module functions
- Edge cases and boundary conditions
### Avoid Testing (Low Value)
- jQuery DOM manipulation internals
- Browser event system mechanics
- Simple property getters/setters
- Framework-provided functionality
### Mocking Strategy
- **Mock system boundaries**: `Date.now()`, `window` properties, external APIs
- **Use real objects**: Prefer actual module instances over mocks
- **Minimal mocking**: Only mock what's necessary for isolation
## Adding New Module Tests
1. **Create test file**: `test-{module}.js` following QUnit patterns:
```javascript
QUnit.module('ModuleName.functionName', function(hooks) {
QUnit.test('description of test', function(assert) {
// Arrange, Act, Assert
const result = ModuleName.functionName(input);
assert.equal(result, expected, 'Function returns expected value');
});
});
```
2. **Update master runner**: Add to `test-all.html`:
```html
<!-- In source modules section -->
<script src="../js/module-name.js"></script>
<!-- In test modules section -->
<script src="test-{module}.js"></script>
```
3. **Optional**: Create individual runner `test-{module}.html` for focused debugging
## Integration with Development Workflow
- **Manual execution**: Part of JavaScript development process
- **PR checklist**: Include "JavaScript tests passing" verification
- **No CI automation**: Lightweight approach prioritizes simplicity
- **Browser compatibility**: Test in target browsers (Firefox, Chrome)
## Future Considerations
- Additional modules can reuse the established pattern
- Test coverage expansion as JavaScript complexity grows
- Potential automation if testing frequency increases significantly
- Maintain local-first philosophy for any framework additions
This approach balances comprehensive testing coverage with development simplicity, providing confidence in JavaScript functionality without complex tooling overhead.