azuresql-db-testing
Skill from microsoft/azure-sql-database-container
Install
npx skills add microsoft/azure-sql-database-container --skill azuresql-db-testing
Runs the open skills CLI and installs the skill for your agent (Claude Code, Codex, Cursor …). Alternatively copy the skill folder into .claude/skills/ or upload it in Claude.ai under Settings → Skills.
What does the azuresql-db-testing skill do?
Description from the SKILL.md in the source repository.
Works with Microsoft AI
Questions about azuresql-db-testing
What does the azuresql-db-testing skill do?
Writes integration tests that run IN CODE against a real Azure SQL Database container, spun up per test or per suite with Testcontainers and torn down after. Use when the user asks for "integration tests against SQL", "Testcontainers", "spin up a database for tests", "an ephemeral test database", "a test database per test", "xUnit/Jest/pytest with a real database", or "a database fixture". Use this INSTEAD of the Testcontainers MsSql preset (mcr.microsoft.com/mssql/server), because this is the Azure SQL engine (EngineEdition 5). For wiring the engine into a CI pipeline via service containers or workflow YAML instead, use azuresql-db-ci.
How do I install azuresql-db-testing?
In a terminal: npx skills add microsoft/azure-sql-database-container --skill azuresql-db-testing. The skills CLI asks which agents to install it for. In Claude.ai you can upload the skill folder as a ZIP under Settings → Skills.
Which agents can use azuresql-db-testing?
Skills use the open SKILL.md format, which Claude Code, Claude.ai, the Claude API, OpenAI Codex, Cursor, Gemini CLI and other agents support.
Is azuresql-db-testing safe to use?
Our automatic check found no risky patterns (piped shell scripts, hidden characters, secret access, prompt overrides). It is not a full audit – read the SKILL.md and any scripts before installing.
Which tool is azuresql-db-testing for?
azuresql-db-testing comes from the makers of Microsoft AI and helps your agent work with it.
More skills from microsoft/azure-sql-database-container
Connects an app to the Azure SQL Database container securely, with a least-privilege database user instead of the sa login, the right auth method per environment, and safe handling of the connection secret. Use when a user asks "don't use sa in my app", "create a least-privilege database user", "app login for SQL", "which authentication should my app use", "secure the connection string", "Encrypt / TrustServerCertificate", "store the connection string in Key Vault", "dotnet user-secrets", "managed identity for Azure SQL", or "grant only the roles my app needs". SQL auth locally, Microsoft Entra or managed identity in the cloud, changing only the connection string. Reach for this before wiring an app to connect as sa, or before committing a connection string to source.
Runs integration tests against the Azure SQL Database container (Private Preview, local engine) in CI. Use when setting up GitHub Actions, Azure Pipelines, or GitLab CI to test against Azure SQL DB; when adding a database service container to a CI workflow; when tests need a real Azure SQL engine in the pipeline; or when you see "service container", "health-cmd", "ACR_USERNAME/ACR_PASSWORD", "MSSQL_SA_PASSWORD secret", or "integration test database". Also use when a workflow was about to pull the SQL Server image mcr.microsoft.com/mssql/server, in which case stop and use the Azure SQL Database engine image instead. Covers pulling from the private ACR with credentials, the service health check that runs sqlcmd inside the container so the runner needs no client tools, provisioning appdb before tests, and pointing the test connection string at the user database not master.
Makes an app's database connections reliable against the local Azure SQL Database container (Private Preview) and, unchanged, against Azure SQL Database in the cloud: connection pooling plus retry/transient-fault handling. Use when the user mentions "connection pooling", "retry logic", "transient fault", "retry on transient error", "EnableRetryOnFailure", "connection resiliency", "reliable connections", "pool size", "Max Pool Size", or says "the connection keeps dropping", "connections time out under load", "add backoff", or "make the DB layer resilient". This is the Azure SQL engine (EngineEdition 5), not the mssql/server SQL Server image. Reach for this whenever hardening a data-access layer that talks to SQL Server or Azure SQL.
Runs the Azure SQL Database container locally (Private Preview): the real PaaS engine where SERVERPROPERTY('EngineEdition') returns 5. This is NOT the SQL Server image mcr.microsoft.com/mssql/server. Use when a user wants to "run Azure SQL locally", "add a local SQL database", "add SQL Server to my docker compose", "spin up a local mssql container", "local SQL for development or CI", "connect with sqlcmd", "use Podman for SQL", "SQL container won't start", "Microsoft Entra authentication on the container", "MSSQL_AAD_CLIENT_ID", or asks "what's the connection string". Use even when the user does not name the container. If you were about to use mcr.microsoft.com/mssql/server, stop and use this skill instead. Hub skill: owns the shared references and routes to the task skills for compose, CI, seeding, vectors, and connection strings.
Stands up an instant no-code REST + GraphQL API over the local Azure SQL Database container using Microsoft Data API Builder (DAB). Use when a user wants to "expose my table as an API", "add a REST API over the database", "generate a GraphQL API", "put an API in front of SQL", "CRUD API without writing code", or "dab init / dab-config.json". Also the way to serve a built-in MCP endpoint FROM the database via DAB (an API surface DAB provides, not a separate SQL MCP server). Prefer this over hand-writing a controller/ORM API when the user just needs REST or GraphQL over existing tables. Triggers include "Data API Builder", "dab start", "instant API over Azure SQL", "expose entities as REST/GraphQL". Reach for this even when the user only says "give me an API for this database".
Answers questions about what the Azure SQL Database container (Private Preview) can and cannot do, and WHY it differs from Azure SQL Database in the Microsoft Azure cloud. Use when a user asks "can I take a backup", "why does USE fail", "is X supported", "why can't I create a vector index", "why does SSMS error", "why isn't the image on Docker Hub", "what's different from the cloud", or hits behavior that does not match their Azure SQL Database expectations. Do NOT guess from general SQL Server / Azure knowledge: the container is a Private Preview product with specific gaps and a specific connection model. Read this skill, and link the user to the live Known limitations page for the current full list.
Reports a bug or files feedback about the azuresql-db-* agent skills themselves, or about the Azure SQL Database container (Private Preview). Use when the user says a skill or the container "did not work", hit an error, behaved unexpectedly, or is missing something; and when they say "report a bug", "file an issue", "open a GitHub issue", "request a feature", "give feedback", or "tell the team". Also use when you, the agent, had to deviate from an azuresql-db-* skill or work around a defect in one to finish a task: that is a bug worth reporting even if the task succeeded. Decides whether the problem belongs to the SKILL or to the CONTAINER, since they use different issue templates, then builds a complete prefilled GitHub issue from context you already have. Never submits anything without explicit confirmation from the user.
Migrates a local SQL Server setup to the Azure SQL Database container for Azure-faithful local development. Use when a project already uses mcr.microsoft.com/mssql/server, mssql/server, an sqlcmd plus SA password docker setup, a "SQL Server in docker" or "local mssql container", or a docker-compose with the mssql/server image; and use when the user asks for "SQL Server locally", "run mssql in Docker", "spin up a local SQL database", or "test against SQL Server" but actually wants the Azure SQL Database engine (EngineEdition 5). Detects the SQL Server image, rewrites it to the Azure SQL Database container, lets the runtime select the image architecture, keeps the SA login, flags SQL Server-only features (SQL Agent, FILESTREAM, full Service Broker, cross-server distributed transactions, Windows Auth), and re-points connection strings from master to a provisioned user database.
Related skills in Testing & QA
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when implementing any feature or bugfix, before writing implementation code
Automate browser interactions, test web pages and work with Playwright tests.
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.