Emerging Trends in Software Engineering

Context
- C++20 project "clubhub", GoogleTest via FetchContent.
- RegistrationService::registerStudent(studentId, eventId)
  throws std::runtime_error when the event is full and
  std::invalid_argument when the student is already
  registered for that event.

Task
Write GoogleTest cases for registerStudent that cover the
capacity boundaries (capacity - 1, capacity, capacity + 1),
a duplicate registration, and an event in the past.

Constraints
- Use only the public API in the header below.
- Do not invent helper functions; list every assumption.
- Use made-up names and ids only (no real student data).

<paste include/clubhub/RegistrationService.hpp here>

A good prompt gives context, one clear task, constraints and the real interface. It asks for assumptions, so that you can check them.

AI draft for "register a student if there is room"

// Compiles, reads well, passes the happy-path test.
Registration RegistrationService::registerStudent(
    const std::string& studentId, const std::string& eventId)
{
    const Event& event = events_.get(eventId);
    if (registrations_.exists(studentId, eventId)) {
        throw std::invalid_argument("already registered");
    }
    if (registrations_.countFor(eventId) <= event.capacity()) {
        return registrations_.add(studentId, eventId,
                                  RegistrationStatus::Registered);
    }
    throw std::runtime_error("event is full");
}

// Fix after review: strictly less than
if (registrations_.countFor(eventId) < event.capacity()) {

The test that catches it (boundary value analysis, Chapter 09)

TEST(RegistrationServiceTest, RejectsWhenEventIsFull) {
    InMemoryEventRepository events;
    InMemoryRegistrationRepository regs;
    events.save(makeEvent("E1", /*capacity=*/2));
    RegistrationService service{events, regs};

    service.registerStudent("S1", "E1");
    service.registerStudent("S2", "E1");

    EXPECT_THROW(service.registerStudent("S3", "E1"),
                 std::runtime_error);
    EXPECT_EQ(regs.countFor("E1"), 2);
}

[ RUN      ] RegistrationServiceTest.RejectsWhenEventIsFull
registration_service_test.cpp:23: Failure
Expected: service.registerStudent("S3", "E1") throws an
  exception of type std::runtime_error.
  Actual: it throws nothing.
registration_service_test.cpp:24: Failure
Expected equality of these values:
  regs.countFor("E1")
    Which is: 3
  2
[  FAILED  ] RegistrationServiceTest.RejectsWhenEventIsFull

struct SearchFilter {
    std::optional<std::string> category;
    std::optional<std::chrono::year_month_day> from;
    std::optional<std::chrono::year_month_day> to;
};

// Model output is untrusted input: check it like any
// other data that crosses a trust boundary.
bool isValid(const SearchFilter& f,
             const std::set<std::string>& known) {
    if (f.category && !known.contains(*f.category)) {
        return false;
    }
    if (f.from && f.to && *f.to < *f.from) {
        return false;
    }
    return true;
}

• Measure what matters for the feature: accuracy, invalid-output rate, safety cases such as prompt injection, latency, cost per 100 requests.
• A demo with three hand-picked queries proves nothing; a fixed eval set makes changes comparable.

Cloud-native software is designed to run on elastic, provider-managed infrastructure: packaged in containers, configured from the environment, observable, and replaced rather than repaired when something goes wrong. The Cloud Native Computing Foundation (CNCF) hosts many of the open-source tools.

# Stage 1: build and test with the full toolchain
FROM ubuntu:24.04 AS build
RUN apt-get update \
 && apt-get install -y g++ cmake git
WORKDIR /src
COPY . .
RUN cmake -S . -B build -DCMAKE_BUILD_TYPE=Release \
 && cmake --build build \
 && ctest --test-dir build

# Stage 2: small runtime image, no compiler inside
FROM ubuntu:24.04
COPY --from=build /src/build/clubhub /usr/local/bin/
ENV CLUBHUB_DATA_DIR=/data
USER 1000
ENTRYPOINT ["clubhub"]

A multi-stage build: the tests run inside the build, and the final image contains only the program. Containers were introduced in Chapter 08.

• Microservices: many small services, each owning its data and deployed on its own. They let many teams release independently and scale parts separately, at the price of network failures, distributed data and much more operations work.
• Conway's law (Melvin Conway, 1968): a system's structure tends to mirror the communication structure of the organisation that builds it.
• For Club Hub (one team, one release per sprint): a modular monolith. Enforce the module boundaries with CMake targets:

# Modules as CMake targets: dependencies are explicit
add_library(clubhub_events src/events/event.cpp)
add_library(clubhub_registrations
            src/registrations/registration_service.cpp)
target_link_libraries(clubhub_registrations
                      PUBLIC clubhub_events)
add_executable(clubhub src/main.cpp)
target_link_libraries(clubhub PRIVATE
                      clubhub_registrations)

• Platform engineering: a platform team builds an internal developer platform so that product teams can create a repository, a pipeline or an environment by self-service instead of opening tickets.
• Golden path: the supported, well-documented default way to do a common task. Teams may leave it, but then they own the extra work.
• Goal: reduce the cognitive load of product teams (the "platform team" and "stream-aligned team" terms come from Team Topologies, Skelton and Pais, 2019).
• Risk: a platform nobody asked for. Treat it as a product with users, feedback and a roadmap.

# .github/workflows/ci.yml in a team repository
name: ci
on: [push, pull_request]
jobs:
  build-test:
    # golden path from a (hypothetical) platform team
    uses: itc-platform/ci/.github/workflows/cpp.yml@v2
    with:
      compilers: '["gcc-13", "clang-17"]'
      sanitizers: true
      sbom: true

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:5f2c1c9e-6b1a-4d7e-9a43-0c1d2e3f4a5b",
  "version": 1,
  "metadata": {
    "timestamp": "2026-11-30T09:00:00Z",
    "component": { "bom-ref": "clubhub", "type": "application",
                   "name": "clubhub", "version": "1.2.0" }
  },
  "components": [
    { "bom-ref": "googletest", "type": "library",
      "name": "googletest", "version": "1.15.2", "scope": "excluded",
      "licenses": [ { "license": { "id": "BSD-3-Clause" } } ],
      "purl": "pkg:github/google/googletest@v1.15.2" },
    { "bom-ref": "nlohmann-json", "type": "library",
      "name": "nlohmann_json", "version": "3.11.3", "scope": "required",
      "licenses": [ { "license": { "id": "MIT" } } ],
      "purl": "pkg:github/nlohmann/json@v3.11.3" }
  ],
  "dependencies": [
    { "ref": "clubhub", "dependsOn": [ "nlohmann-json" ] }
  ]
}

• An SBOM (software bill of materials) is the ingredient list of a product: each component, its version, licence, a unique identifier (the purl, package URL) and how components depend on each other.
• Two common formats: CycloneDX (OWASP) and SPDX (Linux Foundation, also ISO/IEC 5962:2021). Both use JSON among others.
• Why: when a vulnerability is announced in a library, you search your SBOMs and know in minutes which products and releases contain it. It also supports the licence review of Chapter 03.
• "scope": "excluded" marks GoogleTest as used for testing only, not shipped. The JSON library is listed only if your team stores data as JSON.
• As of 2026 several governments require or recommend SBOMs for software they buy or that is sold in their market (for example the EU Cyber Resilience Act).
• Generators exist for containers and many package managers; for C++ with FetchContent they detect less, so review the result by hand and update it with every release.

• Large vendors (for example Microsoft and the Chromium project) have reported that roughly 70 % of their serious security bugs were memory-safety issues; government security agencies have since urged a move to memory-safe languages (Rust, Java, C#, Go, Python) for new code.
• For existing C++ the guidance is: follow the C++ Core Guidelines, use modern library types, and run sanitizers and static analysis in CI. The C++ committee is working on hardening and safety profiles for future standards.

Risky: C-style ownership and indexing

// Simplified Event(title, capacity) for the example.
// Who deletes this object, and on which paths?
Event* makeEvent() {
    return new Event{"Hackathon", 50};
}

int totalCapacity(const Event* events, int n) {
    int total = 0;
    // i <= n reads one element past the end
    for (int i = 0; i <= n; ++i) {
        total += events[i].capacity();
    }
    return total;
}

const Event& firstEvent(const std::string& file) {
    std::vector<Event> all = loadEvents(file);
    // dangling: 'all' is destroyed on return
    return all.front();
}

Modern C++20: ownership and bounds in the types

std::unique_ptr<Event> makeEvent() {
    return std::make_unique<Event>("Hackathon", 50);
}

int totalCapacity(std::span<const Event> events) {
    int total = 0;
    for (const Event& e : events) {
        total += e.capacity();
    }
    return total;
}

std::optional<Event> firstEvent(const std::string& file) {
    std::vector<Event> all = loadEvents(file);
    if (all.empty()) {
        return std::nullopt;
    }
    // a copy, not a reference into 'all'
    return all.front();
}

// When an index is unavoidable: checked access,
// throws std::out_of_range instead of reading garbage.
const Event& e = events.at(i);

# .github/workflows/ci.yml (excerpt)
on:
  push:
    paths-ignore: ['**.md', 'docs/**']
  pull_request:
# cancel a running job when a newer push arrives
concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

## Radar entry: AI code assistants
Ring: Trial        Quadrant: Tools        Date: 2026-11-30
What: editor assistants that suggest code, tests and
  explanations.
Why this ring: in our 4-hour PoC it drafted 14 GoogleTest
  cases for CsvEventRepository; we accepted 9, edited 3,
  rejected 2 (one asserted nothing, one used an invented
  helper). Coverage of the file rose from 58 % to 81 %.
Conditions: review checklist on every AI-assisted PR,
  label "ai-assisted", no personal data in prompts.
Evidence: lab11/poc/findings-log.md, PR #41, PR #43
Review again: start of next semester

## Radar entry: PWA for Club Hub
Ring: Assess       Quadrant: Platforms    Date: 2026-11-30
What: a web app that can be installed on a phone and
  works offline through a service worker; one code base
  for web and mobile.
Why this ring: fits students' phones and weak campus
  Wi-Fi, but our core is a C++ CLI; a PWA needs a web
  API first.
Risks: offline registrations can conflict with capacity;
  push notification support differs between browsers.
Next step: 4-hour PoC, a static mock of the event list
  from exported JSON, tested on two phones.

Arithmetic for A: 0.30×5 + 0.20×3 + 0.15×3 + 0.20×3 + 0.15×4 = 1.50 + 0.60 + 0.45 + 0.60 + 0.60 = 3.75

B: 0.90 + 1.00 + 0.75 + 1.00 + 0.75 = 4.40 · C: 1.20 + 0.40 + 0.30 + 0.60 + 0.60 = 3.10

# ADR-011: Front end for the week-14 release
Status: accepted · 2026-11-30
Context: the C++ core and CLI work; students
  want phone access; one week left; no web API.
Options: A PWA now, B CLI + HTML report,
  C cross-platform native app (matrix above).
Decision: B (adopt now). The PWA stays in
  Assess; revisit next semester with a PoC.
Consequences:
  + no new risk before the demo
  + effort goes to tests and the report
  - no phone access this semester
  - the PWA question stays open
Review date: start of next semester

An architecture decision record (ADR, Chapter 10) keeps the reasoning; the radar keeps the current ring.