Shift-Left Testing
The software testing world has polarized around two strategies: shift-left (test early, in development) and shift-right (test in production, with real users). The debate is false. The best engineering teams do both — and understanding when each applies is the key to shipping reliable software at speed. What Is Shift-Left Testing?
CI/CD
The Dagger Python SDK lets you write CI pipelines as ordinary Python functions. No YAML, no DSL — just Python. You can import Dagger functions like any library, test them with pytest, and run them locally with the same command that runs in CI. This guide focuses on practical patterns: running
CI/CD
Dagger.io flips the CI/CD model on its head: instead of YAML pipelines that are impossible to test locally, you write your pipelines in Python, TypeScript, or Go — and run them anywhere. The same pipeline runs on your laptop, in GitHub Actions, and in GitLab CI without modification. This
CI/CD
Both Dagger and GitHub Actions run your tests in CI. The difference is how you define and debug those pipelines. This guide compares them on the things that matter when you're running test suites: local execution, caching, services, parallelism, and debugging when something breaks. The Core Difference GitHub
Shift-Left Testing
The best QA engineers in the world can't keep up with the pace of modern software development. When a team ships code multiple times per day, a separate testing team becomes the bottleneck — no matter how good they are. Developer-led testing is the answer. Not because QA teams
Shift-Left Testing
Most teams say they care about quality. Fewer have a culture where quality actually happens. The difference isn't intention — it's the systems, habits, and shared values that make testing automatic rather than afterthought. Building a testing culture in an agile team isn't a one-time
CI/CD
The Dagger TypeScript SDK lets you write CI pipelines in TypeScript — the same language as your application. Your pipeline is type-safe, unit-testable, and runs identically on your laptop and in GitHub Actions. This guide focuses on Node.js and Next.js testing workflows: running Vitest, Jest, Playwright, and integrating with
CI/CD
Integration tests that hit real databases and message queues are harder to run than unit tests. In GitHub Actions, you configure service containers in YAML and hope they start before your tests run. In Dagger, you define services as code, bind them to your test container, and get the same
Testing
Performance is a feature in games. A 60 FPS game feels completely different from the same game at 30 FPS. Players notice stutters, long load times, and frame drops — and they stop playing. Performance testing catches regressions before players experience them. This guide covers tools and techniques for profiling game
Testing
Webhook signature verification is the one security control standing between your server and arbitrary POST requests. If you're not testing it, you're trusting that your implementation is correct — which is how security bugs get shipped. This guide covers how to test HMAC and JWT signature verification
Testing
MQTT is the backbone of most IoT systems — lightweight, broker-based, designed for unreliable networks. Testing MQTT is different from testing REST APIs: you're testing asynchronous publish/subscribe flows, quality of service levels, retained messages, and broker behavior under load. This guide covers practical MQTT testing strategies from unit
Playwright
Playwright offers three paths to AI-assisted test generation: classic codegen for manual recording, the new Generator agent for AI-driven creation from a plan, and the @playwright/test-generator programmatic API. Each fits a different workflow. This guide shows all three with real code examples. Key Takeaways Classic npx playwright codegen records