Juan Pablo juanpabloaj

Guide for Test Development and Response Crafting

This document establishes the principles and guidelines for creating automated tests (unit, integration, E2E) and formulating technical responses. The goal is to produce code that is robust, maintainable, and clearly justified, and to provide answers that demonstrate a deep analysis and a complete understanding of the problem.

Part 1: Philosophy and Analysis Process — Think Before Coding

The quality of a test is not measured by its code, but by the thought process that precedes it.

Deep Analysis First, Code Later: Before writing a single line of test code, perform a thorough analysis of the function or module to be tested. Your response should begin with this section, describing:

The Business Objective: What real-world problem does this function solve? What business questions should it answer? Do not simply describe what the code does; explain why it exists.

Running Integration Tests Without Docker in the Codex environment

This guide explains how to execute the integration test suite in an environment where docker or docker-compose are unavailable. Ensure neither tool is installed before continuing. If either command prints a version number, use the container-based workflow instead.

# Check for docker and docker-compose
command -v docker && docker --version
command -v docker-compose && docker-compose --version

1. Core Coding Principles

Language: All code, comments, variable names, function names, class names, and commit messages must be strictly in English.
Idiomatic Style:
- Write code that adheres to the idiomatic style, conventions, and official style guides of the target language. This includes formatting, naming, and general structure.
- Assume a linter or formatter will eventually run; aim to produce code that is already close to passing common linting rules.
Clarity and Readability:
- Prioritize clarity, readability, and maintainability over unnecessary "cleverness" or extreme brevity if it sacrifices understanding.
- Write self-documenting code.
Follow the Principle of Least Surprise: code should behave in a way that users and other developers would naturally expect.

	Role: Act as an Autonomous QA Engineer, an expert agent in software test automation. Your mission is to set up your own working environment idempotently, systematically explore a web application, manage a persistent state, and generate a robust test suite using Python and Playwright.

	Working Philosophy:

	1. Idempotency (Core Principle): Your first task is always to ensure the environment is configured, but without performing redundant actions. If a folder or file already exists, you acknowledge it and continue. You log every setup action you perform so you never repeat it.
	2. Statefulness: You never start from scratch. You read your `qa_state.json` file to know the testing progress, discovered elements, and environment configuration.
	3. Efficiency: You verify dependencies before installing them. You optimize your workflow to maximize coverage.
	4. Robustness and Clarity: You generate tests with stable selectors and clear assertions. Your work is understandable, and you leav

	package main

	import (
	"sync"
	"testing"
	"time"
	)

	type Actor interface {
	Perform()

	import subprocess
	import json
	import os
	from datetime import datetime

	import logging

	import base64
	from io import BytesIO
	from PIL import Image, ImageDraw

	'''
	it shows a log message when an object is detected.

	references

	https://medium.com/@sebastiaan.panasj/occupancy-counting-with-unitv2-by-m5stack-d35455037882
	'''

	import subprocess
	import json

	package main

	import (
	"context"
	"log/slog"
	"os"
	)

	type contextKey string

	import os
	import sqlite3
	from linkedin_api import Linkedin
	import logging


	def extract_id(urn):
	return urn.split(":")[-1]

	.env
	*.db