Testing
mix test is the entry point for all Elixir testing. While ExUnit handles test structure and assertions, mix test controls how tests are discovered, filtered, and executed. This guide covers the configuration knobs that matter most in production Elixir projects — from test tagging to coverage reporting to CI pipeline setup.
Testing
ShadCN UI components are well-designed and accessible. What they're not, by default, is performance-tested for your specific usage. A DataTable with 50 rows behaves differently than one with 50,000 rows. A Combobox with 100 options is fine; with 10,000 options, it depends on how
Testing
Testing Elixir applications that use Ecto requires understanding one core mechanism: the SQL sandbox. Get it right, and you can run hundreds of database tests in parallel with full isolation. Get it wrong, and you have flaky tests that pass individually but fail when run together. This guide covers the
PWA Testing
Service workers are powerful but notoriously difficult to test. They run in a separate thread, control network requests, manage caches, and have a complex lifecycle with install, activate, and fetch events. When a service worker misbehaves, it can silently break your entire app — serving stale content, blocking requests, or failing
Testing
Elementary is an open-source dbt package that adds data observability to your existing dbt project. It turns dbt models into monitored data assets: tracking volume changes, schema changes, freshness, and statistical anomalies in column distributions — without changing your existing dbt tests. Where dbt's built-in tests (not_
Testing
Serverspec lets you write RSpec tests for server infrastructure. Instead of logging into a box and manually checking whether nginx is running or a firewall rule is in place, you describe the expected state in code and run it as a test suite. Originally created for testing Chef and Puppet
Testing
Serverless integration testing is harder than testing a monolith. Functions are isolated by design, services communicate through events and queues, and the infrastructure is someone else's computer. The same properties that make serverless scalable and cheap also make it annoying to test. This guide covers the strategies that
Testing
Unit tests with mocked AWS SDK calls tell you that your function logic is correct. They don't tell you whether your DynamoDB queries actually work, whether your S3 key paths are right, or whether your SQS message format triggers the right Lambda. LocalStack fills that gap: it runs
Testing
Electron apps often use native OS APIs to feel like real desktop apps rather than web apps in a window. System tray icons, desktop notifications, file system dialogs, shell operations — these give your app its desktop feel. They're also notoriously hard to test. The challenge: native APIs produce
Serverless
The Serverless Framework has become the de facto standard for deploying multi-cloud serverless applications. But most teams using it focus on deployment and skip the testing layer — or end up with a fragile test setup that requires a live AWS environment to run. A well-structured Serverless Framework project
Testing
End-to-end testing a serverless architecture is fundamentally different from testing a traditional server. Your "application" is a graph of functions, queues, databases, and managed services. A user action might trigger five Lambda functions sequentially, write to DynamoDB, publish to SQS, and fire a webhook — all before
Testing
Inter-Process Communication (IPC) is the nervous system of an Electron app. The renderer process (UI) can't directly access Node.js APIs — it communicates with the main process via IPC channels. When IPC breaks, the app breaks. When IPC is poorly tested, bugs hide at the process boundary