Testing Guide

Key Takeaways

Testing validates that software works as intended. It spans multiple levels—unit through acceptance—and includes both manual and automated approaches. Choosing the right testing strategy (TDD, BDD, or pure automation) depends on team collaboration needs and project constraints.

Testing Levels

Level	Scope	Who Tests	Example
Unit	Single function/method	Developer	Testing Add() in isolation
Integration	Multiple components together	QA/Developer	Database + API working together
System	Entire application	QA	End-to-end user workflows
Acceptance	Business requirements met	Customer/QA	Feature meets acceptance criteria

Testing Types & Approaches

Type	Knowledge	Focus	When to Use
Black-Box	No internal code knowledge	Inputs/outputs, user perspective	User acceptance testing
White-Box	Full internal knowledge	Code paths, logic branches	Unit testing, debugging
Gray-Box	Partial internal knowledge	Component behavior + external interaction	Integration testing
Functional	Does it work?	Feature correctness	All test levels
Non-Functional	Performance, security, usability	Speed, reliability, user experience	Load/security/accessibility tests

Interview Angle

“What’s the difference between unit and integration testing?” Unit tests isolate single components and run fast (milliseconds). Integration tests combine modules to catch communication issues—slower but critical for real-world behavior. Think of the testing pyramid: many unit tests (base), fewer integration tests (middle), minimal end-to-end tests (top).

Test Techniques

Boundary Value Analysis: Test at the edges of input ranges (e.g., length = 0, 1, max-1, max).

Equivalence Partitioning: Divide inputs into groups that behave similarly; test one from each group.

Decision Table Testing: Map conditions to expected outcomes for complex business logic.

TDD vs BDD vs Gherkin

Aspect	TDD	BDD	Gherkin
Approach	Write test → Fail → Code → Pass → Refactor	Collaboration-first; define behavior in plain language	DSL (Domain-Specific Language) for BDD
Audience	Developers	Tech + non-tech stakeholders	Business analysts, QA, developers
Output	Unit tests & code	Executable specs & living documentation	Feature files with scenarios
Tools	NUnit, xUnit, JUnit, PyTest	Cucumber, SpecFlow, Behave	Gherkin syntax (used within BDD tools)
Focus	Implementation quality	Behavior correctness & alignment	Human-readable test definitions

Interview Angle

“What is BDD and how does it differ from TDD?” TDD is developer-centric: write a test, watch it fail, write code to pass it. BDD adds a collaboration layer—write the behavior that business wants in plain English, then developers code to that spec. BDD bridges the gap between “what engineers think we need” and “what the business actually needs.”

Gherkin Syntax & Example

Gherkin uses Given/When/Then/And/But to describe scenarios in plain language:

• Given: Initial state or context
• When: Action or event
• Then: Expected outcome
• And/But: Additional conditions (chains to any clause)

Example:

Feature: User login
  Scenario: Successful login with valid credentials
    Given the user is on the login page
    When the user enters valid credentials
    Then the user is redirected to the homepage
    And a welcome message is displayed

Parameterization (testing multiple datasets):

Scenario Outline: Login with various roles
  Given the user has role <role>
  When the user logs in
  Then they see the <dashboard> dashboard

  Examples:
    | role     | dashboard |
    | admin    | Admin     |
    | user     | User      |
    | guest    | Guest     |

TDD Example in C#

[Test]
public void Should_AddTwoNumbers_Correctly()
{
    var calculator = new Calculator();
    var result = calculator.Add(2, 3);
    Assert.AreEqual(5, result);
}

BDD & CI/CD Integration

Interview Angle

BDD interview essentials: How do you parameterize tests in Gherkin? (Scenario Outline + Examples). How do you integrate BDD into a pipeline? (Run Cucumber/SpecFlow as part of CI/CD; treat feature files as acceptance criteria). Why use BDD over TDD alone? (Shared language eliminates rework; non-technical stakeholders can verify logic without reading code).

Automation Testing

What to automate? Repetitive tests, multi-dataset scenarios, and high-effort manual tests. Avoid automating unstable features or tests that rarely run.

Tools & Languages:

Tool	Primary Use	Language Support
Selenium	Web automation	Java, Python, C#, JS
Playwright	Modern web testing	Python, JS, C#, Java
Postman	API testing	Built-in scripting
SpecFlow	BDD automation (.NET)	C#
Cucumber	BDD automation	Java, JS, Python, C#

Framework Types:

• Data-Driven: Tests parameterized with external data (CSV, Excel, DB)
• Keyword-Driven: Reusable keywords (abstraction layer over test steps)
• Hybrid: Combines data-driven + keyword-driven
• BDD: Gherkin-based automation (highest readability)

Maintenance is critical: Update tests as UI/APIs evolve, debug flaky tests quickly, and optimize suite runtime to avoid timeout nightmares.

Common Gotchas

Don’t automate unstable features—if the app crashes mid-test, your automation suite crashes too. Never skip unit tests for E2E only—integration tests can’t catch all bugs and run slower. Plan test data strategy early—generating, managing, and cleaning test data is often 50% of automation effort. Avoid test interdependencies—tests must run independently; shared state = cascading failures.

Resources & Next Steps

Start with unit tests (fastest feedback loop). Move to integration tests once components interact. Add BDD when stakeholder alignment is critical. Reserve E2E automation for high-value, stable workflows. Measure test coverage but don’t obsess—100% coverage doesn’t guarantee bug-free code.

---

Questions? Explore SOLID & Code Quality, .NET Patterns, or Git Cheatsheet for more engineering guides.