Testing
242 bites tagged Testing — interview questions with model answers, and 60-second explainers.
Mocking: Faking Dependencies in Unit Tests
A mock is a stunt double for a real object in your unit tests, letting you control its behavior. Use it to fake dependencies like network clients for fast, predictable tests. The footgun: over-mocking can create tests that pass but miss real integration bugs.
Test-Driven Development: Write the Test First
TDD flips the script: write a failing test before the feature code, forcing a testable design. It's ideal for new Swift components with clear requirements, ensuring every line of code serves a purpose.
XCTAssert: The Pass/Fail Gatekeeper of Your Tests
XCTAssert functions are the gatekeepers of your tests, asserting if code behaves as expected. Use them to validate conditions like equality (`XCTAssertEqual`) or truth (`XCTAssertTrue`).
XCTest: Apple's Built-in Testing Framework
XCTest is your built-in toolbox for writing unit, performance, and UI tests in Xcode. Use it to verify individual functions or simulate user interactions. A common footgun is writing tests that depend on each other; they must be independent to be reliable.
Fuzz Testing in Rust with cargo-fuzz
Fuzz testing automatically finds bugs by feeding your code pseudo-random inputs. Use `cargo-fuzz` to stress-test parsers and APIs that handle untrusted data. The main footgun is assuming random bytes are enough; effective fuzzing needs structure-aware inputs.
Go Fuzz Testing: Automated Bug Discovery
Go's fuzz testing automatically generates strange inputs to crash your code, finding bugs you'd never think to test. It's ideal for stress-testing parsers or security-sensitive functions.
Rust Mocking: Using Traits as Test Seams
Mocking in Rust uses traits as test doubles. You program a mock's behavior—what calls to expect and what to return—to isolate the code under test. The `mockall` crate's `#[automock]` macro generates mocks from traits. The footgun is over-specifying behavior.
Mocking in Go: Swap Real Code for Test Doubles
Mocking in Go uses interfaces to swap slow dependencies like `time.Sleep` with fast fakes in tests, keeping your test suite quick. Use it for network calls or database access. The footgun is testing implementation details instead of observable behavior.
Go Test Coverage: Rewriting Source to See What's Untested
Go's coverage tool rewrites your source code, adding counters to see what's executed during tests. It's a powerful way to find untested code, but remember: high coverage doesn't guarantee your tests are actually checking for correctness.
Rust Unit Tests: Co-locating Tests with Code
In Rust, unit tests live inside a special `tests` module within the same file as the code they're testing. This lets you test a module in isolation, including its private functions.
Go Table-Driven Tests: Test More with Less Code
Instead of copy-pasting tests, define inputs and expected outputs in a table (a slice or map) and loop through them. This is the idiomatic Go way to test functions with many edge cases. The main footgun is a closure bug in parallel tests; re-shadow the.
Go's Race Detector: Find Concurrency Bugs at Runtime
The Go race detector finds data races by watching memory access at runtime. Use `go test -race` in CI or on a canary instance, but remember: it only catches races that actually execute. If your tests don't trigger the race, it won't be found.
Go Benchmarking: Measure, Don't Guess
Go's benchmark runner finds stable performance numbers by repeatedly calling your code in a loop controlled by b.N. Use it to optimize hot paths or compare algorithm implementations. Forgetting b.ResetTimer() will include setup costs, skewing your results.
cargo test: Rust's All-in-One Test Runner
`cargo test` is Rust's built-in test runner, automatically discovering and executing unit, integration, and documentation tests. Use it to validate code marked with `#[test]` and examples in docs.
Performance Profiling in Tests
Performance profiling in tests means capturing frame build and raster times during a scripted, automated run instead of eyeballing smoothness, so jank regressions get caught in CI before they ever reach a real device.
Generating Code Coverage Reports in Dart
Code coverage shows which lines your tests execute. It's a health check for your test suite's reach, not a measure of code quality. Use the `coverage` package to generate reports for CI/CD. The footgun is that high coverage doesn't prove correctness.
Mocking Dependencies in Flutter with Mockito
Mockito creates fake, controllable versions of your app's dependencies, like an API client. This is crucial for unit tests, letting you isolate code from external systems to make tests fast, reliable, and independent of network or database availability.
Flutter Widget Testing: Verifying UI in Isolation
Widget testing is like testing a single actor's performance without the full play. It lets you build, interact with, and verify a single UI component in isolation, making it faster than a full app test and more comprehensive than a unit test.
CI/CD for Flutter: Automate Your Builds and Releases
CI/CD for Flutter is a safety net that automatically builds, tests, and deploys your app. Use it to catch bugs early and ship updates to app stores without manual steps.
Testing Flutter Platform Channel Interactions
Mock platform channels to test your Dart code's interaction with native APIs without a real device. Use this for unit tests of features like camera or GPS access. Footgun: These tests only verify the Dart side, not that your native code is correct.
Golden File Testing: Visual Regression for Widgets
Golden file testing is a 'spot the difference' game for your UI, catching visual regressions by comparing a widget's rendering to a master image. Use it to lock down critical widget appearances.
WidgetTester: Programmatically Drive Your Flutter UI
WidgetTester is a robot user for your app, programmatically tapping, dragging, and entering text. Use it in `testWidgets` to simulate user flows and verify UI state. The footgun is forgetting `tester.pump()` after an action; you'll assert against a stale UI.
Finding Widgets with Flutter's Finder Class
Finder is your magnifying glass for widget tests, letting you locate specific widgets in the tree. It describes what to find, while the WidgetTester does the actual finding. The footgun is assuming a finder returns only one widget when it might match several.
Dart's `expect` and Matchers: Writing Better Tests
Dart's `expect` and Matchers are a grammar for your tests, letting you define complex rules beyond simple equality. Use them to verify values, check for exceptions, and test async Futures/Streams.
Get Testing bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.