
Quarkus Tdd
Run test-first development on Quarkus 3.x services with JUnit 5, Camel route tests, and JaCoCo coverage gates before you merge event-driven Java APIs.
Overview
Quarkus TDD is an agent skill most often used in Build (also Ship testing) that enforces a test-first Quarkus 3.x workflow with JUnit 5, Camel and messaging tests, and JaCoCo coverage targets.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill quarkus-tddWhat is this skill?
- Red-green-refactor loop with tests written before implementation
- @Nested JUnit 5 unit layout with Mockito and REST Assured integration patterns
- Apache Camel, CompletableFuture, and LogContext propagation test scenarios
- JaCoCo enforcement targeting 80%+ combined unit and integration coverage
- Explicit triggers for bug fixes, refactors, and conditional flow logic
- 80%+ JaCoCo coverage target (unit + integration)
- JUnit 5 with @Nested organization pattern
- Quarkus 3.x LTS focus
Adoption & trust: 1.1k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are changing Quarkus services and Camel event flows without a repeatable test-first routine or a clear coverage bar before merge.
Who is it for?
Solo or indie builders maintaining Quarkus 3.x APIs, Camel integrations, or RabbitMQ-driven services who want structured TDD prompts in the agent.
Skip if: Teams on non-Quarkus stacks, front-end-only work, or repos that already forbid test-first workflow and only need one-off manual QA scripts.
When should I use this skill?
Adding Quarkus features or REST endpoints, fixing bugs, refactoring event-driven services, or testing Camel routes, RabbitMQ handlers, reactive streams, CompletableFuture async, and LogContext propagation.
What do I get? / Deliverables
You get failing-then-passing JUnit and integration suites, refactors guarded by green tests, and JaCoCo-backed confidence toward 80%+ coverage on the paths you touched.
- Failing-then-passing unit and integration test classes
- Minimal production code changes that satisfy tests
- JaCoCo report aligned to 80%+ target on touched modules
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the skill governs how you implement REST endpoints, repositories, and Camel handlers—not only how you gate releases. Backend fits Quarkus services, data access, security rules, reactive streams, and RabbitMQ event handlers that the workflow examples center on.
Where it fits
Scaffold failing REST Assured tests for a new create-order endpoint before touching OrderService.
Raise JaCoCo coverage on Camel and RabbitMQ paths before tagging a release candidate.
Refactor conditional flow logic only after @Nested unit tests document every branch.
Reproduce a production bug with a failing test, patch minimally, and keep regression coverage green.
How it compares
Use as a JVM TDD playbook inside the agent instead of generic “write some tests” chat without Quarkus, Camel, or JaCoCo specifics.
Common Questions / FAQ
Who is quarkus-tdd for?
Java and Quarkus developers shipping REST and event-driven services who want agent-guided test-first implementation with Mockito, REST Assured, and Camel testing patterns.
When should I use quarkus-tdd?
Use it in Build when adding endpoints or data access, in Ship when fixing bugs or raising coverage before release, and whenever you refactor Camel routes, RabbitMQ handlers, or async CompletableFuture flows.
Is quarkus-tdd safe to install?
Review the Security Audits panel on this Prism page and your org policy before enabling any skill; the skill describes test and build workflows that may imply running Maven/Gradle and local AWS or broker fixtures you control.
SKILL.md
READMESKILL.md - Quarkus Tdd
# Quarkus TDD Workflow TDD guidance for Quarkus 3.x services with 80%+ coverage (unit + integration). Optimized for event-driven architectures with Apache Camel. ## When to Use - New features or REST endpoints - Bug fixes or refactors - Adding data access logic, security rules, or reactive streams - Testing Apache Camel routes and event handlers - Testing event-driven services with RabbitMQ - Testing conditional flow logic - Validating CompletableFuture async operations - Testing LogContext propagation ## Workflow 1. Write tests first (they should fail) 2. Implement minimal code to pass 3. Refactor with tests green 4. Enforce coverage with JaCoCo (80%+ target) ## Unit Tests with @Nested Organization Follow this structured approach for comprehensive, readable tests: ```java @ExtendWith(MockitoExtension.class) @DisplayName("OrderService Unit Tests") class OrderServiceTest { @Mock private OrderRepository orderRepository; @Mock private EventService eventService; @Mock private FulfillmentPublisher fulfillmentPublisher; @InjectMocks private OrderService orderService; private CreateOrderCommand validCommand; @BeforeEach void setUp() { validCommand = new CreateOrderCommand( "customer-123", List.of(new OrderLine("sku-123", 2)) ); } @Nested @DisplayName("Tests for createOrder") class CreateOrder { @Test @DisplayName("Should persist order and publish fulfillment event") void givenValidCommand_whenCreateOrder_thenPersistsAndPublishes() { // ARRANGE doNothing().when(orderRepository).persist(any(Order.class)); // ACT OrderReceipt receipt = orderService.createOrder(validCommand); // ASSERT assertThat(receipt).isNotNull(); assertThat(receipt.customerId()).isEqualTo("customer-123"); verify(orderRepository).persist(any(Order.class)); verify(fulfillmentPublisher).publishAsync(receipt); verify(eventService).createSuccessEvent(receipt, "ORDER_CREATED"); } @Test @DisplayName("Should reject missing customer id") void givenMissingCustomerId_whenCreateOrder_thenThrowsBadRequest() { // ARRANGE CreateOrderCommand invalid = new CreateOrderCommand("", validCommand.lines()); // ACT & ASSERT WebApplicationException exception = assertThrows( WebApplicationException.class, () -> orderService.createOrder(invalid) ); assertThat(exception.getResponse().getStatus()).isEqualTo(400); verify(orderRepository, never()).persist(any(Order.class)); verify(fulfillmentPublisher, never()).publishAsync(any()); } @Test @DisplayName("Should record error event when persistence fails") void givenPersistenceFailure_whenCreateOrder_thenRecordsErrorEvent() { // ARRANGE doThrow(new PersistenceException("database unavailable")) .when(orderRepository).persist(any(Order.class)); // ACT & ASSERT PersistenceException exception = assertThrows( PersistenceException.class, () -> orderService.createOrder(validCommand) ); assertThat(exception.getMessage()).contains("database unavailable"); verify(eventService).createErrorEvent( eq(validCommand), eq("ORDER_CREATE_FAILED"), contains("database unavailable") ); verify(fulfillmentPublisher, never()).publishAsync(any()); } @Test @DisplayName("Should reject null commands") void givenNullCommand_whenCreateOrder_thenThrowsNullPointerException() { // ACT & ASSERT assertThrows( NullPointerException.class, () -> orderService.createOrder(null) ); verify(orderRepository, never()).persist(any(Order.class))