Quality Assurance IV, Clean Code

What is the difference between statement vs. branch coverage?

- Statement Coverage: Ensures each line of code runs at least once.

- Branch Coverage: Ensures every possible branch (true/false decisions) is tested.

Testing at Tech Giants - Shift Left Testing

Test early in dev cycle.

- Use CI/CD pipelines for auto tests.

- Developers write unit/integration tests

.- Google requires passing unit tests before code merges.

CI/CD Pipeline

- Continuous Integration / Continuous Deployment pipelines automate build, test, and deployment

.- Runs tests frequently to catch bugs early.

Automated Testing at Scale

- Automate all test types (unit, integration, UI).

- Use AI to detect anomalies & generate tests.

- Run tests in parallel in cloud.

- Facebook runs millions of tests daily.

Chaos Engineering for Resilience

- Intentionally break systems to test recovery.

- Use tools like Chaos Monkey.

- Monitor recovery speed.

- Amazon uses Game Days to simulate failures.

Canary Releases & A/B Testing

- Release to small user set first.

- Measure performance & errors.

- Roll back on failure

.- Microsoft uses feature flags to toggle feature

Observability & Monitoring

- Log everything centrally.

- Use distributed tracing to monitor requests.

- AI-based alerts for anomalies.

- Google SRE teams use real-time dashboards.

Clean Code: Why important?

- Cleaner code = better programmers.

- Easier to understand, maintain, and extend.

Clean Code - Characteristics

- Elegant, efficient, readable like prose.

- Simple, direct.

- Looks like it's written by someone who cares.

- High expressiveness, low duplication.

Good Naming Practices

- Use intention-revealing, searchable, pronounceable names.

- Avoid encodings and disinformation.

- Good class names: nouns (e.g., Customer, WikiPage).

- Good method names: verbs (e.g., postPayment, saveFile).

Function Guidelines

- Keep them small (<20 lines).

- Do one thing only.

- Use top-down structure (called function appears above called function).

- Use descriptive names.

Arguments in Functions

- Prefer fewer arguments: 0 ideal, 1–2 okay, 3+ justify, 4+ avoid.

- Use objects to group arguments (e.g., use Point instead of x and y).

Comments - When to Use

- Use only when code cannot be self-explanatory.

- Prefer readable code over needing comments.

- Use informative or explanatory comments.

- Mark TODOs clearly.

- Avoid noise/redundant comments.

Class Guidelines

- Keep classes small.

- SRP (Single Responsibility Principle): each class has one reason to change.

- Organize: constants, variables, public functions, then private helpers.