Compliance Statement: This document fulfills the testing requirements of the Hack23 Secure Development Policy as mandated by ISO 27001 (A.12.1.4), NIST CSF (PR.IP-2), and CIS Controls (16.8).

• Testing Objectives
• Testing Strategy
• Test Infrastructure
• Coverage Metrics
• Module Testing Approach
• Test Execution
• Quality Gates
• Continuous Improvement
• Compliance & Standards

The Citizen Intelligence Agency maintains comprehensive unit testing to ensure:

• ✅ 80% minimum line coverage across all production modules
• ✅ 70% minimum branch coverage for critical business logic
• ✅ 90%+ coverage for security and authentication components
• ✅ 100% coverage for utility and validation classes
• ✅ Zero critical security vulnerabilities in tested code paths
• ✅ Public transparency through live coverage reporting

• Quality Assurance: Prevent regressions through automated testing
• Security Validation: Test security controls and authentication flows
• Maintainability: Enable safe refactoring with comprehensive test suite
• Documentation: Tests serve as executable specifications
• Compliance: Meet ISO 27001, NIST CSF, and CIS Controls requirements

The project uses strict naming conventions to distinguish unit tests from integration tests:

• Suffix: *Test.java
• Characteristics:
  • Pure unit tests with mocked dependencies
  • No database access or external API calls
  • Fast execution (< 1 second per test)
  • No Spring context or infrastructure required
• Examples: RiksdagenDateUtilTest, ApiDtoSanityTest, RemoveDataManagerTest
• Maven execution: Included in standard mvn test runs

• Suffix: *ITest.java
• Characteristics:
  • Tests requiring database access
  • Tests calling external APIs
  • Tests using Spring application context
  • Slower execution, require infrastructure
• Examples: WorldbankTopicApiImplITest, DataDAOITest, UserHomeITest
• Maven execution: Excluded from unit test runs using -Dtest='!**ITest*,!**DocumentationTest*'

The citizen-intelligence-agency/build.xml and workflows use this exclusion pattern:

mvn test -Dtest='!**ITest*,!**DocumentationTest*'

This ensures unit tests run quickly in CI/CD without external dependencies, while integration tests can be run separately when infrastructure is available.

Our testing strategy follows the industry-standard test pyramid approach:

                    /\
                   /  \
                  / E2E \         10% - End-to-End Tests
                 /  Tests \       (Critical user journeys)
                /----------\
               /            \
              / Integration  \    20% - Integration Tests
             /     Tests      \   (Component interactions)
            /------------------\
           /                    \
          /     Unit Tests       \ 70% - Unit Tests
         /________________________\ (Isolated component testing)

• Purpose: Test individual classes and methods in isolation
• Scope: Single class or component
• Speed: < 1 second per test
• Dependencies: Mocked using Mockito
• Execution: Every commit, every PR

• Purpose: Test component interactions and data flow
• Scope: Multiple components, database operations
• Speed: < 10 seconds per test
• Dependencies: Spring Test Context, H2 in-memory database
• Execution: Every commit, every PR

• Purpose: Test complete features and user scenarios
• Scope: Full application stack
• Speed: < 30 seconds per test
• Dependencies: Embedded containers, test database
• Execution: Pre-merge, nightly builds

The project uses JaCoCo Maven Plugin for comprehensive coverage reporting:

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.14</version>
    <executions>
        <execution>
            <id>pre-unit-test</id>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        <execution>
            <id>post-unit-test</id>
            <phase>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Report Locations:

• 📊 JaCoCo HTML Reports: target/site/jacoco/index.html (per module)
• 📊 SonarCloud Dashboard: https://sonarcloud.io/summary/new_code?id=Hack23_cia
• 📊 GitHub Pages: https://hack23.github.io/cia/jacoco/

✓ Line Coverage:   80% minimum (global)
✓ Branch Coverage: 70% minimum (global)
✓ Security Modules: 90% minimum (line coverage)
✓ Utility Classes:  100% recommended

Coverage thresholds are enforced through:

1. Maven Build: JaCoCo plugin fails build if thresholds not met
2. SonarCloud Quality Gate: Blocks PRs below coverage targets
3. GitHub Actions: CI workflow validates coverage on every commit

The CIA project consists of 48 Maven modules organized into logical categories:

API integration models for external Swedish government services:

• Riksdagen (Parliament) API Models (9 modules)

  • model.external.riksdagen - Core parliament data
  • model.external.riksdagen.documentcontent.impl - Document content
  • model.external.riksdagen.dokumentlista.impl - Document lists
  • model.external.riksdagen.dokumentstatus.impl - Document status
  • model.external.riksdagen.person.impl - Person data
  • model.external.riksdagen.personlista.impl - Person lists
  • model.external.riksdagen.utskottsforslag.impl - Committee proposals
  • model.external.riksdagen.votering.impl - Voting records
  • model.external.riksdagen.voteringlista.impl - Voting lists

• Val (Election Authority) Models (5 modules)

  • model.external.val - Core election data
  • model.external.val.kommunvalkrets.impl - Municipal districts
  • model.external.val.landstingvalkrets.impl - County districts
  • model.external.val.partier.impl - Political parties
  • model.external.val.riksdagsvalkrets.impl - Parliamentary districts

• World Bank Models (5 modules)

  • model.external.worldbank - Core World Bank data
  • model.external.worldbank.countries.impl - Country data
  • model.external.worldbank.data.impl - Economic indicators
  • model.external.worldbank.indicators.impl - Indicator metadata
  • model.external.worldbank.topic.impl - Topic classifications

• model.common.api - Common model interfaces
• model.common.impl - Common model implementations
• model.internal.application - Application domain models
• model.internal.application.user.impl - User and security models

Testing Strategy for Models:

• ✅ Entity validation tests
• ✅ JAXB marshaling/unmarshaling roundtrip tests
• ✅ JPA entity mapping verification
• ✅ Equals/hashCode contract validation
• ✅ Serialization compatibility tests

Example Test Pattern:

@Test
public void testRoundtripSerialization() {
    DocumentData original = createTestData();
    String xml = marshal(original);
    DocumentData deserialized = unmarshal(xml);
    assertEquals(original, deserialized);
}

• service.api - Service interfaces and contracts
• service.impl - Core service implementations

• service.component.agent.api - Agent component interfaces
• service.component.agent.impl - Agent component implementations

• service.data.api - DAO interfaces
• service.data.impl - DAO implementations (Hibernate/JPA)

• service.external.common - Common integration utilities
• service.external.esv - Swedish Financial Management Authority integration
• service.external.riksdagen - Parliament API integration
• service.external.val - Election Authority integration
• service.external.worldbank - World Bank API integration

Testing Strategy for Services:

• ✅ Business logic validation with unit tests
• ✅ Transaction management verification
• ✅ Exception handling scenarios
• ✅ External API mocking (Mockito)
• ✅ Database operations with H2 in-memory
• ✅ Spring context integration tests

Example Test Pattern:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class ServiceIntegrationTest {
    
    @Autowired
    private UserService userService;
    
    @Mock
    private ExternalApiClient apiClient;
    
    @Test
    public void testServiceOperation() {
        when(apiClient.fetchData()).thenReturn(mockData);
        Result result = userService.processData();
        verify(apiClient, times(1)).fetchData();
        assertNotNull(result);
    }
}

• citizen-intelligence-agency - Main Vaadin web application
• web-widgets - Reusable UI components

Testing Strategy for Web:

• ✅ Spring MVC controller tests
• ✅ Vaadin UI component tests
• ✅ Security filter chain validation
• ✅ Session management tests
• ✅ Integration with service layer
• 📝 E2E tests (separate test plan)

• parent-pom - Parent POM configuration
• parent-model-pom - Model modules parent
• parent-model-external-pom - External models parent
• parent-model-internal-pom - Internal models parent
• parent-model-jpa2-pom - JPA models parent
• parent-service-pom - Service modules parent
• parent-web-pom - Web modules parent
• testfoundation - Common test utilities

Testing Strategy for Infrastructure:

• ✅ Test utility validation
• ✅ Configuration verification
• ✅ Build configuration tests
• ⚙️ Minimal direct testing (build-time validation)

• cia-dist-deb - Debian package distribution
• cia-dist-cloudformation - AWS CloudFormation templates
• jms-broker - JMS message broker configuration
• encrypt.properties - Property encryption utilities

Testing Strategy for Distribution:

• ✅ Package assembly verification
• ✅ Configuration validation
• ✅ Integration smoke tests
• 🚀 Deployment validation (separate E2E tests)

mvn clean test

mvn clean test jacoco:report

cd model.external.riksdagen.person.impl
mvn test

# After running tests with jacoco:report
open target/site/jacoco/index.html

Tests are automatically executed on:

• ✅ Every Commit: Fast unit tests on all branches
• ✅ Pull Requests: Full test suite + coverage analysis
• ✅ Merge to Main: Integration tests + deployment validation
• ✅ Nightly Builds: Extended test suite + performance tests

GitHub Actions Workflow:

name: CI Build
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up JDK 26
        uses: actions/setup-java@v4
        with:
          java-version: '26'
      - name: Run Tests
        run: mvn clean test jacoco:report
      - name: SonarCloud Analysis
        run: mvn sonar:sonar

All pull requests must pass the following quality gates:

• ✅ All tests must pass (0 failures)
• ✅ No compilation errors
• ✅ No test timeouts

• ✅ Minimum 80% line coverage (global)
• ✅ Minimum 70% branch coverage (global)
• ✅ No decrease in overall coverage (delta ≥ 0%)

• ✅ Quality Gate: "Passed"
• ✅ Zero critical vulnerabilities
• ✅ Zero blocker issues
• ✅ Maintainability rating: A or B
• ✅ Security rating: A

• ✅ CodeQL analysis: No new alerts
• ✅ Dependency Check: No critical CVEs
• ✅ OWASP ZAP: No high-severity findings

Builds fail if:

• ❌ Any test fails
• ❌ Coverage drops below 80%/70%
• ❌ New critical security vulnerabilities introduced
• ❌ SonarCloud quality gate fails

• Weekly Reviews: Coverage trend analysis in team meetings
• Monthly Reports: Test effectiveness metrics and flaky test analysis
• Quarterly Goals: Coverage improvement targets per module

• Flaky Test Management: Tests with >1% failure rate are investigated immediately
• Performance Monitoring: Tests taking >1s (unit) or >10s (integration) are optimized
• Obsolete Test Cleanup: Redundant tests removed during refactoring
• Test Naming Standards: Descriptive names following should_expectedBehavior_when_stateUnderTest pattern

• Write tests before fixing bugs (TDD approach)
• Keep tests independent and isolated
• Use meaningful test names describing behavior
• Mock external dependencies
• Test both success and failure scenarios
• Include edge cases and boundary conditions
• Maintain test data builders/factories
• Review test coverage in code reviews

• Don't test framework code or third-party libraries
• Don't write tests dependent on execution order
• Don't use production data in tests
• Don't skip tests instead of fixing them
• Don't write overly complex tests
• Don't test implementation details
• Don't commit commented-out tests

This testing approach satisfies:

• A.12.1.4 - Separation of development, testing and operational environments
  • ✅ Separate test environments with H2 database
  • ✅ Test data isolation from production
  • ✅ Automated test execution in CI/CD

• PR.IP-2 - Secure Development Lifecycle
  • ✅ Unit testing integrated into development process
  • ✅ Automated security testing (CodeQL, OWASP)
  • ✅ Coverage reporting and quality gates

• 16.8 - Maintain up-to-date test scripts and processes
  • ✅ Comprehensive test documentation
  • ✅ Version-controlled test code
  • ✅ Regular test review and updates

• OWASP ASVS (Application Security Verification Standard): Security testing integrated
• IEEE 829 (Software Test Documentation): Structured test planning approach
• ISO/IEC 25010 (Software Quality Requirements): Coverage of quality characteristics

• Architecture Overview - System architecture and design
• Security Architecture - Security controls and design
• Contributing Guidelines - Development workflow and standards
• Data Model - Database schema and entities

• Hack23 ISMS Public Repository
• Secure Development Policy
• Information Security Policy

• JUnit 4 Documentation
• Mockito Documentation
• Spring Testing Guide
• JaCoCo Documentation

Test Infrastructure Questions:

• GitHub Issues: https://github.com/Hack23/cia/issues
• Security Issues: security@hack23.com (see SECURITY.md)

Project Leadership:

• Maintainer: James Sörling
• Organization: Hack23 AB
• Website: https://www.hack23.com

Coverage trends and historical data available at:

• SonarCloud Dashboard: https://sonarcloud.io/summary/new_code?id=Hack23_cia
• GitHub Actions: https://github.com/Hack23/cia/actions
• GitHub Pages Reports: https://hack23.github.io/cia/

Document Version: 1.0
Last Updated: 2025-11-14
Next Review: 2026-02-14 (Quarterly)
Owner: Hack23 AB Development Team
Compliance Status: ✅ ISMS-Compliant