Making generated code reliable

How can you check that an AI-assisted change complies with business rules without introducing a regression?

  • Lovable
  • Claude Code
  • Codex

1960 € per session, excl. VAT

In short

“Writing and running automated tests” is a private in-person session of a full day for developers using AI to modify an existing application or quality leads and technical professionals responsible for validating changes to business functionality. It helps you translate business rules into verifiable scenarios. Groups of up to 12 participants, in French, with exercises on your own work cases.

Why this training?

Generated code may appear consistent while reversing a condition, overlooking a boundary or changing existing behaviour. Tests make these discrepancies visible before a change is approved. Tests that are themselves generated may reproduce errors in the code. The training therefore separates business requirements from their implementation, requires verified assertions and measures the suite’s ability to detect a deliberate defect. Running case study: The fictitious organisation Avelune Consignes manages locker bookings. Its application must reject a booking that exceeds available capacity, prevent duplicates and free up a space after cancellation. A change to the availability calculation introduces a regression that participants must detect and then correct. Transfer to the workplace: For an authorised change to business functionality, reuse the risk matrix, add a regression test and attach the execution results to the code review. Then compare execution times and intermittent failures to guide maintenance.

Objectives of this training

  • Translate business rules into verifiable scenarios.
  • Prioritise unit and integration tests according to risk.
  • Write assertions that are independent of the code being tested.
  • Run a suite and diagnose its failures.
  • Measure regression detection and document limitations.

Who is it for and what are the prerequisites?

Roles and tasks concerned

  • Developers using AI to modify an existing application.
  • Quality leads and technical professionals responsible for validating changes to business functionality.

Prior skills

  • Be able to read and modify code in the language of the supplied project.
  • Know how to install dependencies and run a development command.
  • Have previously used a code generation assistant.

What you will work on

  1. Turn rules into evidence

    Objective: Define expected results independently of the code. Business risk, standard case, capacity limits and transitions after cancellation.

  2. Prepare an isolated run

    Objective: Establish a reproducible test baseline. Unit and integration tests; reinitialised data, simulated dependencies, secrets management.

  3. Produce and then review assertions

    Objective: Build tests that genuinely verify the rules. Contextualised instructions, arrange-act-assert, precise assertions; code generation and modification with Lovable, Claude Code or Codex depending on the authorised environment.

  4. Verify interactions

    Objective: Check the consistency of the booking journey. Persistence, duplicates, cancellation and separation between simulation and integration.

  5. Diagnose and correct a regression

    Objective: Distinguish an application defect from a test defect. Reading traces, diagnostic hypotheses, fail-correct-rerun cycle.

  6. Measure and hand over

    Objective: Evaluate the suite without confusing coverage with reliability. Duration, stability, coverage if available, blind spots and test maintenance.

What you take away

  • Matrix of business rules, risks and scenarios.
  • Reviewed test suite and isolated datasets.
  • Execution report before and after correction.
  • Rerun instructions and list of known limitations.

Method and assessment

  • Short explanations followed by immediate practice on the running case study.
  • Individual work followed by work in pairs, with cross-review of outputs.
  • Guided group discussion: what works, what needs correcting and what remains a human decision.
  • Preparation: Prepare a training project that can run locally, with verified dependencies and test command. Check access to tools authorised by the organisation; use only fictitious or anonymised data, with no secrets in the instructions.

Observable criteria: Each priority rule has a standard case, a boundary case and an expected rejection. ; A deliberate defect causes the corresponding test to fail before correction. ; Three successive runs produce the same results on reinitialised data. ; The report states the command, environment, duration, passes and failures. ; The assertions are reviewed and no secrets appear in exchanges or deliverables..

Frequently asked questions

Do you need to use all three tools?

No. One authorised environment is sufficient; consult each tool’s official documentation for the exact conditions.

Are generated tests reliable straight away?

No. Expected results and assertions require human review and verification using a deliberate defect.

Does high coverage prove the absence of bugs?

No. It indicates code that has been exercised, not the relevance of assertions or the completeness of scenarios.

Does the day include a production deployment?

No. Runs remain within the training environment; any real-world use follows the organisation’s approval procedures.

Last updated: