Battery Modeling App

Tools, prerequisites, and learning objectives

Tools: Ubuntu terminal (Linux or Windows with WSL), g++ supporting C++17, Git, Bash, a GitHub account, and an optional editor. File projects use supplied text fixtures. Week 3 also uses GDB; Week 8 uses compiler sanitizers.

Prerequisites: Classes, constructors, access control, and member functions.

Objectives: Encapsulate state; construct valid objects; test public behavior.

Provisional course alignment: C++ implementation, problem solving, development tools, testing, and technical communication; team projects additionally assess collaboration. Exact official syllabus objective numbers have not been supplied.

g++ --version
git --version
# Install missing tools in Ubuntu:
sudo apt update
sudo apt install build-essential git gdb

1. Agree on requirements and tests

• Model private battery capacity and remaining charge.
• Use a constructor plus methods to consume charge and report remaining charge.
• Prevent negative capacity, negative consumption, and consumption above available charge.

Required test scenarios

• Capacity 100, consume 30 gives 70 remaining
• Consume exactly capacity gives zero
• Overconsumption is rejected without changing state

Before coding, agree on exact input/output formats and expected results for these scenarios. Add one extra edge case of your own. This assignment deliberately does not supply the application solution.

2. Assign responsibilities

Assign implementation, testing, automation, and documentation/release roles; combine the last two for a three-person team. Rotate roles from last week. Every member must commit meaningful work, run the tests, and review a teammate’s pull request.

3. Set up GitHub collaboration

One member creates week06-mini-project with a README and invites collaborators. Create issues for requirements, implementation, tests, CI, and documentation. Each member runs:

git clone https://github.com/TEAM-OWNER/week06-mini-project.git
cd week06-mini-project
git switch -c feature/YOUR-TASK
mkdir -p src tests .github/workflows
printf "build/\n" > .gitignore

4. Implement and test in the terminal

Create src/main.cpp and test fixtures from your agreed specification. Adapt the class project’s test.sh to your application, including every required scenario. Do not retain its expected results unchanged.

mkdir -p build
g++ -std=c++17 -Wall -Wextra -pedantic src/main.cpp -o build/app
./build/app < tests/input1.txt > build/actual1.txt
diff -u tests/expected1.txt build/actual1.txt
bash test.sh

For a different command-line interface, update both README and test.sh consistently. Tests must return a nonzero exit status on failure.

5. Add automated checks

Use this workflow to run your team’s own test script:

cat > .github/workflows/cpp.yml <<'EOF'
name: Build and test
on: [push, pull_request]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Compile and run acceptance tests
        run: bash test.sh
EOF

Prove it detects a failure: push an intentional mismatch on a branch, inspect the failed run, then correct it before merging. Keep evidence of both runs.

6. Review, merge, and synchronize

git status
git add YOUR-CHANGED-FILES
git commit -m "Describe your completed feature and tests"
git push -u origin feature/YOUR-TASK

Replace placeholders with actual file and branch names. Open a pull request linked to its issue. A teammate reviews correctness, tests, naming, and generated files. Resolve feedback and merge after CI passes.

git switch main
git pull --ff-only
git switch -c feature/NEXT-TASK

7. Reproduce and release

cd ..
git clone https://github.com/TEAM-OWNER/week06-mini-project.git week06-team-verify
cd week06-team-verify
bash test.sh
git tag -a v1.0 -m "Verified Week 6 mini project"
git push origin v1.0

Have someone other than the implementation lead perform this check. Record each member’s contributions and review links in CONTRIBUTIONS.md.

Deliverables and assessment

• Repository and tagged-release links; complete source, tests, and Actions workflow.
• README: setup, input/output contract, terminal commands, limitations, and AI-use disclosure.
• Passing CI plus a demonstrated failure/correction.
• Reviewed pull requests, contribution record, and each member’s terminal evidence.
• Short demo explaining the week-specific concepts and design tradeoffs.