From 5a9fea9da72e81e8197770a84616057b69589831 Mon Sep 17 00:00:00 2001 From: 0xJohnnyboy Date: Thu, 20 Aug 2026 13:33:24 +0200 Subject: [PATCH 1/3] test: cover project directory configuration --- ...8-20-project-directory-regression-tests.md | 83 +++++++++++++++++++ tests/scretch_spec.lua | 57 +++++++++++++ 2 files changed, 140 insertions(+) create mode 100644 specs/2026-08-20-project-directory-regression-tests.md diff --git a/specs/2026-08-20-project-directory-regression-tests.md b/specs/2026-08-20-project-directory-regression-tests.md new file mode 100644 index 0000000..71dcfd5 --- /dev/null +++ b/specs/2026-08-20-project-directory-regression-tests.md @@ -0,0 +1,83 @@ +# Spec: Tests de non-régression des répertoires projet + +## 1. Meta + +- Date : 2026-08-20 +- Statut : Approved +- Portée : tests Lua du module `scretch` + +## 2. Contexte / Problème + +La PR #11 corrige une lecture invalide de `config.use_project.dir` en +`config.use_project_dir`. Les tests existants ne couvraient pas les branches où +les répertoires projet sont activés, ce qui a laissé passer la régression. + +## 3. Objectifs + +- Protéger le choix du répertoire projet pour les scratchs et les templates. +- Protéger le comportement de `auto_create_project_dir`. +- Vérifier le comportement via l'API publique du module. + +## 4. Non-objectifs + +- Modifier le comportement ou la configuration du plugin. +- Tester les modes temporaires déjà couverts par d'autres tests. +- Ajouter une nouvelle infrastructure de test ou de CI. + +## 5. Scope + +### In + +- Tests unitaires pour `use_project_dir.scretch = true`. +- Tests unitaires pour `use_project_dir.template = true`. +- Cas `auto_create_project_dir = true` et `false`. + +### Out + +- Modes `auto`, `global` et commandes interactives. +- Accès réel au système de fichiers. + +## 6. Risques et Impacts + +- Risque faible de couplage aux détails internes, limité en observant les + commandes et appels simulés produits par l'API publique. +- Aucun impact sur les données, la sécurité ou les performances de production. +- Rollback : retrait des seuls cas de test ajoutés. + +## 7. Approche proposée + +Étendre le harnais existant pour exposer son répertoire de travail et les +dossiers créés, puis appeler `setup` avec les configurations projet. Déclencher +une opération publique qui consomme chaque répertoire et vérifier que le chemin +utilisé est construit à partir du répertoire de travail courant et du chemin +relatif configuré, ainsi que la création conditionnelle du dossier. + +## 8. Alternatives considérées + +- Tester directement les fonctions internes : rejeté car plus couplé à + l'implémentation. +- Utiliser de vrais dossiers temporaires : rejeté car le harnais simule déjà le + système de fichiers de façon déterministe. + +## 9. Plan d'implémentation + +1. Exposer le répertoire de travail simulé et `created_dirs` dans le contexte + de test. +2. Ajouter les cas scratch et template avec création activée. +3. Ajouter la vérification que la création reste désactivée par défaut. + +## 10. Plan de test + +- Exécuter `nvim --headless -u NONE -l tests/run.lua`. +- Vérifier que la suite échouerait si le chemin de configuration fautif était + réintroduit. + +## 11. Critères d'acceptation + +- AC-1 : un scratch en mode projet utilise, sans erreur, le chemin relatif + `scretch_project_dir` résolu depuis le répertoire de travail courant. +- AC-2 : un template en mode projet utilise, sans erreur, le chemin relatif + `template_project_dir` résolu depuis le répertoire de travail courant. +- AC-3 : avec `auto_create_project_dir = true`, le répertoire choisi est créé. +- AC-4 : avec `auto_create_project_dir = false`, aucun répertoire n'est créé. +- AC-5 : toute la suite de tests existante reste verte. diff --git a/tests/scretch_spec.lua b/tests/scretch_spec.lua index 495d3f4..e0eaeb9 100644 --- a/tests/scretch_spec.lua +++ b/tests/scretch_spec.lua @@ -150,6 +150,8 @@ local function with_module(test_fn) notifications = notifications, fs = fs, files = files, + cwd = cwd, + created_dirs = created_dirs, set_input = function(v) input_value = v end, set_current_file = function(v) current_file = v end, } @@ -201,6 +203,61 @@ with_module(function(t) assert_eq(captured.cwd, "/tmp/scretch-tests/.scretch/templates/", "project mode should force project template dir") end) +with_module(function(t) + local project_dir = ".project-scretches/" + local expected_dir = t.cwd .. "/" .. project_dir + t.module.setup({ + use_project_dir = { + auto_create_project_dir = true, + scretch = true, + scretch_project_dir = project_dir, + } + }) + t.module.new() + assert_eq(t.cmds[#t.cmds], "vsplit " .. expected_dir .. "scretch_1.txt", + "project scretch dir should be relative to cwd") + assert_truthy(t.created_dirs[expected_dir], "enabled project scretch dir should be created") +end) + +with_module(function(t) + local captured = nil + local project_dir = ".project-templates/" + local expected_dir = t.cwd .. "/" .. project_dir + package.loaded["fzf-lua"] = { + files = function(opts) + captured = opts + end + } + t.module.setup({ + backend = "fzf-lua", + use_project_dir = { + auto_create_project_dir = true, + template = true, + template_project_dir = project_dir, + } + }) + t.module.edit_template() + assert_truthy(captured ~= nil, "edit_template should call configured backend") + assert_eq(captured.cwd, expected_dir, "project template dir should be relative to cwd") + assert_truthy(t.created_dirs[expected_dir], "enabled project template dir should be created") +end) + +with_module(function(t) + local project_dir = ".existing-scretches/" + local expected_dir = t.cwd .. "/" .. project_dir + t.module.setup({ + use_project_dir = { + auto_create_project_dir = false, + scretch = true, + scretch_project_dir = project_dir, + } + }) + t.module.new() + assert_eq(t.cmds[#t.cmds], "vsplit " .. expected_dir .. "scretch_1.txt", + "project scretch dir should still be selected when auto-create is disabled") + assert_eq(t.created_dirs[expected_dir], nil, "disabled auto-create should not create project dir") +end) + with_module(function(t) t.set_input("") t.module.new_named() From 02ffd4600a821143ca23256be06e02c3397fbf34 Mon Sep 17 00:00:00 2001 From: 0xJohnnyboy Date: Thu, 20 Aug 2026 13:35:02 +0200 Subject: [PATCH 2/3] ci: run tests on pull requests --- .github/workflows/tests.yml | 29 +++++++ .../2026-08-20-pull-request-test-workflow.md | 81 +++++++++++++++++++ 2 files changed, 110 insertions(+) create mode 100644 .github/workflows/tests.yml create mode 100644 specs/2026-08-20-pull-request-test-workflow.md diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml new file mode 100644 index 0000000..ce221b7 --- /dev/null +++ b/.github/workflows/tests.yml @@ -0,0 +1,29 @@ +name: Tests + +on: + pull_request: + +permissions: + contents: read + +concurrency: + group: tests-${{ github.event.pull_request.number }} + cancel-in-progress: true + +jobs: + lua-tests: + name: Lua tests + runs-on: ubuntu-latest + timeout-minutes: 5 + + steps: + - name: Checkout pull request + uses: actions/checkout@v7.0.1 + + - name: Install stable Neovim + uses: rhysd/action-setup-vim@v1.6.1 + with: + neovim: true + + - name: Run tests + run: nvim --headless -u NONE -l tests/run.lua diff --git a/specs/2026-08-20-pull-request-test-workflow.md b/specs/2026-08-20-pull-request-test-workflow.md new file mode 100644 index 0000000..a84509a --- /dev/null +++ b/specs/2026-08-20-pull-request-test-workflow.md @@ -0,0 +1,81 @@ +# Spec: Tests automatiques sur les pull requests + +## 1. Meta + +- Date : 2026-08-20 +- Statut : Approved +- Portée : GitHub Actions + +## 2. Contexte / Problème + +Les pull requests ne lancent actuellement aucun test du plugin. GitGuardian est +le seul check visible et ne détecte pas les régressions fonctionnelles Lua. + +## 3. Objectifs + +- Exécuter la suite Lua sur chaque pull request. +- Rendre le résultat bloquant et visible dans les checks GitHub. +- Garder le workflow rapide, déterministe et à permissions minimales. + +## 4. Non-objectifs + +- Tester plusieurs systèmes d'exploitation ou versions de Neovim. +- Déployer, publier des artefacts ou modifier le dépôt. +- Exécuter le workflow lors des push directs dans cette première version. + +## 5. Scope + +### In + +- Workflow déclenché par `pull_request`. +- Runner Ubuntu et version stable de Neovim. +- Checkout du code puis exécution de `tests/run.lua` en mode headless. +- Annulation d'une exécution obsolète pour la même pull request. + +### Out + +- Matrice multi-OS/multi-version. +- Couverture de code, cache et artefacts. +- Configuration des branch protection rules sur GitHub. + +## 6. Risques et Impacts + +- Une évolution incompatible de Neovim stable peut faire échouer le workflow ; + ce risque est accepté pour tester la version courante supportée. +- Le code d'une pull request est exécuté sur un runner GitHub isolé, sans secret + et avec `contents: read` uniquement. +- Rollback : suppression du fichier de workflow. + +## 7. Approche proposée + +Ajouter un workflow YAML sous `.github/workflows/` avec un job unique. Installer +Neovim stable via une action dédiée épinglée, checkout le dépôt, puis lancer +`nvim --headless -u NONE -l tests/run.lua`. + +## 8. Alternatives considérées + +- Installer Neovim via APT : rejeté car la version Ubuntu peut être ancienne. +- Ajouter une matrice stable/nightly : différé pour éviter du bruit et un coût + sans besoin de compatibilité explicite à ce stade. +- Exécuter aussi sur `push` vers `main` : différé car la demande vise les PR. + +## 9. Plan d'implémentation + +1. Ajouter le workflow avec permissions minimales et concurrence par PR. +2. Valider la syntaxe et la commande localement autant que possible. +3. Documenter la limite : le check ne devient obligatoire qu'après activation + dans les règles de protection GitHub. + +## 10. Plan de test + +- Vérifier la syntaxe YAML et les clés du workflow. +- Réexécuter localement la commande exacte du job. +- Après push, ouvrir ou mettre à jour une PR pour confirmer le check réel. + +## 11. Critères d'acceptation + +- AC-1 : toute pull request déclenche un job de tests Lua. +- AC-2 : le job checkout le commit de la PR et utilise Neovim stable. +- AC-3 : le job échoue lorsque `tests/run.lua` échoue et réussit sinon. +- AC-4 : le workflow n'accorde que la permission `contents: read`. +- AC-5 : un nouveau commit sur une PR annule son run précédent encore actif. From 755268530e14e71319f6807daee97d5f78620cf3 Mon Sep 17 00:00:00 2001 From: 0xJohnnyboy Date: Thu, 20 Aug 2026 13:36:38 +0200 Subject: [PATCH 3/3] ci: allow manual test runs --- .github/workflows/tests.yml | 3 ++- specs/2026-08-20-pull-request-test-workflow.md | 7 ++++++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index ce221b7..6467cd7 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -2,12 +2,13 @@ name: Tests on: pull_request: + workflow_dispatch: permissions: contents: read concurrency: - group: tests-${{ github.event.pull_request.number }} + group: tests-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: true jobs: diff --git a/specs/2026-08-20-pull-request-test-workflow.md b/specs/2026-08-20-pull-request-test-workflow.md index a84509a..2f20525 100644 --- a/specs/2026-08-20-pull-request-test-workflow.md +++ b/specs/2026-08-20-pull-request-test-workflow.md @@ -14,6 +14,7 @@ le seul check visible et ne détecte pas les régressions fonctionnelles Lua. ## 3. Objectifs - Exécuter la suite Lua sur chaque pull request. +- Permettre de lancer la même suite manuellement depuis GitHub Actions. - Rendre le résultat bloquant et visible dans les checks GitHub. - Garder le workflow rapide, déterministe et à permissions minimales. @@ -28,6 +29,7 @@ le seul check visible et ne détecte pas les régressions fonctionnelles Lua. ### In - Workflow déclenché par `pull_request`. +- Déclenchement manuel sans paramètre via `workflow_dispatch`. - Runner Ubuntu et version stable de Neovim. - Checkout du code puis exécution de `tests/run.lua` en mode headless. - Annulation d'une exécution obsolète pour la même pull request. @@ -61,7 +63,8 @@ Neovim stable via une action dédiée épinglée, checkout le dépôt, puis lanc ## 9. Plan d'implémentation -1. Ajouter le workflow avec permissions minimales et concurrence par PR. +1. Ajouter le workflow avec permissions minimales, déclenchement sur PR et + déclenchement manuel. 2. Valider la syntaxe et la commande localement autant que possible. 3. Documenter la limite : le check ne devient obligatoire qu'après activation dans les règles de protection GitHub. @@ -75,6 +78,8 @@ Neovim stable via une action dédiée épinglée, checkout le dépôt, puis lanc ## 11. Critères d'acceptation - AC-1 : toute pull request déclenche un job de tests Lua. +- AC-1b : le même job peut être lancé manuellement via GitHub Actions, sans + paramètre obligatoire. - AC-2 : le job checkout le commit de la PR et utilise Neovim stable. - AC-3 : le job échoue lorsque `tests/run.lua` échoue et réussit sinon. - AC-4 : le workflow n'accorde que la permission `contents: read`.