技能 testing

🧪

testing

Name: testing
Author: Joseph OBrien

低風險 ⚡ 包含腳本⚙️ 外部命令📁 檔案系統存取

Escribir pruebas con metodología TDD

也可從以下取得: AbdelStark,5t111111,5t111111,ByronWilliamsCPA,CrazySwami,Joseph OBrien

Escribir pruebas después del código conduce a bases de código frágiles y errores no detectados. Esta habilidad ofrece flujos de trabajo TDD estructurados, patrones de pruebas y automatización con Playwright para ayudarte a escribir pruebas mantenibles antes del código, detectar errores temprano y generar confianza en tu software.

支援: Claude Codex Code(CC)

🥉 74 青銅

下載技能 ZIP

在 Claude 中上傳

前往設定 → 功能 → 技能 → 上傳技能

開啟並開始使用

測試它

正在使用「testing」。 Write a failing test first for a calculator add function that returns the sum of two numbers

預期結果:

FASE ROJA - Escribe primero una prueba fallida:
• Crear test_calculator.py con test_add_two_numbers
• La prueba llama a add(2, 3) esperando result == 5
• Ejecutar la prueba - falla con NameError (add no está definido)
FASE VERDE - Implementación mínima:
• Crear calculator.py con def add(a, b): return 5
• La prueba pasa inmediatamente
FASE REFACTOR:
• Cambiar a def add(a, b): return a + b
• Todas las pruebas siguen pasando

安全審計

低風險

v3 • 1/10/2026

Pure documentation skill with minimal code execution. The only executable script (with_server.py) manages local dev servers for testing. Commands are user-provided via CLI arguments, not loaded from external sources. File writes are limited to /mnt/user-data/outputs/ directory. No network exfiltration or credential access detected.

已掃描檔案

2,231

分析行數

發現項

審計總數

低風險問題 (1)

scripts/with_server.py:90-96

Shell execution in with_server.py

The with_server.py script uses subprocess.Popen with shell=True (line 92) to execute user-provided server commands. While this is intentional for supporting shell syntax, shell=True can be risky if commands come from untrusted sources. However, commands are passed via CLI arguments by the user, not loaded from files or network. The code includes # nosec B602 comment indicating intentional use. An attacker controlling command arguments could execute arbitrary commands, but this requires the user to explicitly pass malicious commands.

風險因素

⚡ 包含腳本 (1)

scripts/with_server.py:1-130

⚙️ 外部命令 (1)

scripts/with_server.py:90-96

📁 檔案系統存取 (2)

examples/static-html-automation.py:19-31 examples/console-logging.py:32-33

審計者: claude 查看審計歷史 →

品質評分

架構

100

可維護性

內容

社群

安全

規範符合性

你能建構什麼

Aprender fundamentos de TDD

Empieza escribiendo pruebas que fallen antes del código. Sigue el ciclo Rojo-Verde-Refactor para cada nueva funcionalidad.

Automatizar pruebas web

Usa Playwright para descubrir elementos, completar formularios, capturar logs de consola y verificar estados de página.

Configurar pruebas en CI/CD

Configura etapas de pruebas, puertas de calidad y umbrales de cobertura para pipelines automatizados.

試試這些提示

Configurar infraestructura de pruebas

Ayúdame a configurar la infraestructura de pruebas para mi proyecto de [language] usando [framework]. Muéstrame el flujo de trabajo TDD con un ejemplo simple.

Escribir la primera prueba

Estamos haciendo TDD. Escribe primero una prueba fallida para una función de [feature description] que [expected behavior].

Depurar una prueba fallida

Mi prueba está fallando con [error message]. Analiza si la prueba o la implementación necesitan corrección y muestra el código corregido.

Crear prueba E2E

Escribe un script de Playwright para probar mi app web en localhost:[port]. Descubre botones, enlaces y campos de entrada. Completa un formulario y verifica el envío.

最佳實務

Escribe una sola prueba fallida a la vez. Resiste la tentación de escribir múltiples pruebas o código de implementación.
Mantén las pruebas independientes. Cada prueba debe configurar sus propios datos y no depender de otras pruebas.
Prueba el comportamiento, no la implementación. Verifica los resultados de la API pública en lugar del estado interno.

避免

Escribir pruebas después de la implementación (esto anula el propósito de la disciplina de diseño TDD)
Probar detalles de implementación como atributos privados o contadores internos
Simularlo todo incluyendo el código bajo prueba (el exceso de mocks quita significado a las pruebas)

常見問題

¿Qué frameworks de pruebas admite esta habilidad?

Python (pytest, unittest), JavaScript/TypeScript (Jest, Vitest), Java (JUnit), Go (testing package), Rust (built-in) y Playwright para E2E.

¿Qué umbrales de cobertura debo buscar?

Recomendado: 80% en líneas, funciones, ramas y sentencias. La lógica crítica de negocio (auth, pagos) debe apuntar a 100%.

¿Cómo integro pruebas en CI/CD?

Ejecuta pruebas unitarias en cada commit, pruebas de integración en pull requests y pruebas E2E antes de fusionar a main. Usa umbrales de cobertura como puertas de calidad.

¿Mis datos de prueba están seguros?

Sí. Esta habilidad solo proporciona guía y patrones de ejemplo. No se recopilan, transmiten ni almacenan datos de prueba externamente.

¿Por qué mi script de Playwright no encuentra elementos?

Espera a networkidle antes de inspeccionar apps dinámicas. Usa page.wait_for_load_state('networkidle') después de page.goto(). Prefiere selectores text= y role= sobre selectores CSS frágiles.

¿En qué se diferencia esto de las pruebas predeterminadas de Codex o Claude Code?

Esta habilidad ofrece metodología TDD estructurada, flujos de trabajo específicos de frameworks y patrones detallados de automatización con Playwright más allá de las capacidades básicas de pruebas.