
Añadir parámetros a las anotaciones mediante acciones de reescritura
En esta entrada del blog, haremos lo siguiente:
- Demuestre la búsqueda y la coincidencia de anotaciones
- Anotaciones de amén con plantillas de bigote
Sensei brinda la capacidad de hacer coincidir patrones de código problemáticos y luego modificarlos para adaptarlos a las implementaciones acordadas. En este ejemplo, estoy usando @Disabled sin un parámetro como patrón de código problemático.
Anotación de prueba deshabilitada
Las pruebas deshabilitadas sin un motivo específico pueden resultar problemáticas a largo plazo porque olvidamos por qué las deshabilitamos.
@Disabled
void ThisTestMethodHasNoDisabledReason () {
Assertions.fail («Esta prueba está deshabilitada y no debe ejecutarse»);
}
El riesgo es que, con el tiempo, la base del código avance, la prueba deshabilitada no se actualice de acuerdo con el propósito del código y, finalmente, se vuelva redundante e irrelevante y, potencialmente, nunca se vuelva a habilitar.
Durante las revisiones del código, solemos señalar que es una buena idea añadir una descripción explicativa como parámetro de anotación.
@Disabled («Desactivado para demostrar la adición de un motivo»)
void ThisTestMethodHasDisabledReason () {
Assertions.fail («Esta prueba está deshabilitada y no debe ejecutarse»);
}
Una receta de Sensei
Podemos escribir una receta para detectar cuándo se añade @Disabled sin explicación y una solución rápida que nos recuerde que debemos añadir el motivo real que explica por qué lo hemos desactivado.
Cuando pienso en lo que voy a hacer, tengo que:
- coincide con la anotación deshabilitada sin ningún parámetro
- cambie la anotación deshabilitada para que tenga un parámetro con el texto de marcador «TODO: agregue una descripción aquí»
Crea una receta de advertencia
Utilizo Alt+Enter para crear una nueva receta.

A continuación, añada el texto descriptivo básico en la información general.

Al convertir la regla en una advertencia, cualquier código coincidente se resalta, pero no se muestra como un error evidente.

Encuentra la anotación
En el editor de recetas, cambio la búsqueda para que coincida con una anotación.
Esto resaltará todas las anotaciones en la vista previa.

Una vez hecho esto, quiero filtrar el tipo de anotación.
Podría usar Disabled, pero califico completamente la clase con el paquete para que solo coincida con la anotación de JUnit 5. Como el código fuente se muestra en la vista previa, puedo copiarlo y pegarlo fácilmente desde el código real para evitar errores tipográficos.
Luego quiero hacer coincidir solo las anotaciones sin parámetros, y puedo usar la GUI para hacerlo.

es decir, buscar:
buscar:
anotación:
tipo: «org.junit.jupiter.api.disabled»
sin:
parámetros:
- {}
Crear una acción de corrección rápida de reescritura
Para mi QuickFix usaré una acción de reescritura.
Yo uso el Mostrar variables funcionalidad para mostrarme las variables de Mustache y previsualizar el contenido.

Y luego agrego el código adicional necesario para crear el comentario del marcador de lugar.

es decir, QuickFix:
Correcciones disponibles:
- nombre: «Añadir un parámetro de comentario de todo»
acciones:
- reescribir:
to: «{{{.}}} (\" TODO: añade una descripción aquí\»)»
objetivo: «yo»
Sensei en acción
Hemos creado un breve vídeo que muestra el proceso de creación de recetas en acción.
Resumen
Al crear una solución rápida de reescritura, es más fácil buscar el elemento de código que queremos reescribir, porque entonces es la entidad propia sobre la que podemos actuar.
En este ejemplo, he utilizado una acción de reescritura para modificar la anotación. La reescritura es una acción de uso general que se puede aplicar a cualquier elemento del código y es una buena opción predeterminada para explorar.

Aprenda a usar Sensei para hacer coincidir patrones de código problemáticos y, a continuación, modificarlos para adaptarlos a las implementaciones acordadas con ejemplos de coincidencia de anotaciones.
Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.

En esta entrada del blog, haremos lo siguiente:
- Demuestre la búsqueda y la coincidencia de anotaciones
- Anotaciones de amén con plantillas de bigote
Sensei brinda la capacidad de hacer coincidir patrones de código problemáticos y luego modificarlos para adaptarlos a las implementaciones acordadas. En este ejemplo, estoy usando @Disabled sin un parámetro como patrón de código problemático.
Anotación de prueba deshabilitada
Las pruebas deshabilitadas sin un motivo específico pueden resultar problemáticas a largo plazo porque olvidamos por qué las deshabilitamos.
@Disabled
void ThisTestMethodHasNoDisabledReason () {
Assertions.fail («Esta prueba está deshabilitada y no debe ejecutarse»);
}
El riesgo es que, con el tiempo, la base del código avance, la prueba deshabilitada no se actualice de acuerdo con el propósito del código y, finalmente, se vuelva redundante e irrelevante y, potencialmente, nunca se vuelva a habilitar.
Durante las revisiones del código, solemos señalar que es una buena idea añadir una descripción explicativa como parámetro de anotación.
@Disabled («Desactivado para demostrar la adición de un motivo»)
void ThisTestMethodHasDisabledReason () {
Assertions.fail («Esta prueba está deshabilitada y no debe ejecutarse»);
}
Una receta de Sensei
Podemos escribir una receta para detectar cuándo se añade @Disabled sin explicación y una solución rápida que nos recuerde que debemos añadir el motivo real que explica por qué lo hemos desactivado.
Cuando pienso en lo que voy a hacer, tengo que:
- coincide con la anotación deshabilitada sin ningún parámetro
- cambie la anotación deshabilitada para que tenga un parámetro con el texto de marcador «TODO: agregue una descripción aquí»
Crea una receta de advertencia
Utilizo Alt+Enter para crear una nueva receta.

A continuación, añada el texto descriptivo básico en la información general.

Al convertir la regla en una advertencia, cualquier código coincidente se resalta, pero no se muestra como un error evidente.

Encuentra la anotación
En el editor de recetas, cambio la búsqueda para que coincida con una anotación.
Esto resaltará todas las anotaciones en la vista previa.

Una vez hecho esto, quiero filtrar el tipo de anotación.
Podría usar Disabled, pero califico completamente la clase con el paquete para que solo coincida con la anotación de JUnit 5. Como el código fuente se muestra en la vista previa, puedo copiarlo y pegarlo fácilmente desde el código real para evitar errores tipográficos.
Luego quiero hacer coincidir solo las anotaciones sin parámetros, y puedo usar la GUI para hacerlo.

es decir, buscar:
buscar:
anotación:
tipo: «org.junit.jupiter.api.disabled»
sin:
parámetros:
- {}
Crear una acción de corrección rápida de reescritura
Para mi QuickFix usaré una acción de reescritura.
Yo uso el Mostrar variables funcionalidad para mostrarme las variables de Mustache y previsualizar el contenido.

Y luego agrego el código adicional necesario para crear el comentario del marcador de lugar.

es decir, QuickFix:
Correcciones disponibles:
- nombre: «Añadir un parámetro de comentario de todo»
acciones:
- reescribir:
to: «{{{.}}} (\" TODO: añade una descripción aquí\»)»
objetivo: «yo»
Sensei en acción
Hemos creado un breve vídeo que muestra el proceso de creación de recetas en acción.
Resumen
Al crear una solución rápida de reescritura, es más fácil buscar el elemento de código que queremos reescribir, porque entonces es la entidad propia sobre la que podemos actuar.
En este ejemplo, he utilizado una acción de reescritura para modificar la anotación. La reescritura es una acción de uso general que se puede aplicar a cualquier elemento del código y es una buena opción predeterminada para explorar.
En esta entrada del blog, haremos lo siguiente:
- Demuestre la búsqueda y la coincidencia de anotaciones
- Anotaciones de amén con plantillas de bigote
Sensei brinda la capacidad de hacer coincidir patrones de código problemáticos y luego modificarlos para adaptarlos a las implementaciones acordadas. En este ejemplo, estoy usando @Disabled sin un parámetro como patrón de código problemático.
Anotación de prueba deshabilitada
Las pruebas deshabilitadas sin un motivo específico pueden resultar problemáticas a largo plazo porque olvidamos por qué las deshabilitamos.
@Disabled
void ThisTestMethodHasNoDisabledReason () {
Assertions.fail («Esta prueba está deshabilitada y no debe ejecutarse»);
}
El riesgo es que, con el tiempo, la base del código avance, la prueba deshabilitada no se actualice de acuerdo con el propósito del código y, finalmente, se vuelva redundante e irrelevante y, potencialmente, nunca se vuelva a habilitar.
Durante las revisiones del código, solemos señalar que es una buena idea añadir una descripción explicativa como parámetro de anotación.
@Disabled («Desactivado para demostrar la adición de un motivo»)
void ThisTestMethodHasDisabledReason () {
Assertions.fail («Esta prueba está deshabilitada y no debe ejecutarse»);
}
Una receta de Sensei
Podemos escribir una receta para detectar cuándo se añade @Disabled sin explicación y una solución rápida que nos recuerde que debemos añadir el motivo real que explica por qué lo hemos desactivado.
Cuando pienso en lo que voy a hacer, tengo que:
- coincide con la anotación deshabilitada sin ningún parámetro
- cambie la anotación deshabilitada para que tenga un parámetro con el texto de marcador «TODO: agregue una descripción aquí»
Crea una receta de advertencia
Utilizo Alt+Enter para crear una nueva receta.

A continuación, añada el texto descriptivo básico en la información general.

Al convertir la regla en una advertencia, cualquier código coincidente se resalta, pero no se muestra como un error evidente.

Encuentra la anotación
En el editor de recetas, cambio la búsqueda para que coincida con una anotación.
Esto resaltará todas las anotaciones en la vista previa.

Una vez hecho esto, quiero filtrar el tipo de anotación.
Podría usar Disabled, pero califico completamente la clase con el paquete para que solo coincida con la anotación de JUnit 5. Como el código fuente se muestra en la vista previa, puedo copiarlo y pegarlo fácilmente desde el código real para evitar errores tipográficos.
Luego quiero hacer coincidir solo las anotaciones sin parámetros, y puedo usar la GUI para hacerlo.

es decir, buscar:
buscar:
anotación:
tipo: «org.junit.jupiter.api.disabled»
sin:
parámetros:
- {}
Crear una acción de corrección rápida de reescritura
Para mi QuickFix usaré una acción de reescritura.
Yo uso el Mostrar variables funcionalidad para mostrarme las variables de Mustache y previsualizar el contenido.

Y luego agrego el código adicional necesario para crear el comentario del marcador de lugar.

es decir, QuickFix:
Correcciones disponibles:
- nombre: «Añadir un parámetro de comentario de todo»
acciones:
- reescribir:
to: «{{{.}}} (\" TODO: añade una descripción aquí\»)»
objetivo: «yo»
Sensei en acción
Hemos creado un breve vídeo que muestra el proceso de creación de recetas en acción.
Resumen
Al crear una solución rápida de reescritura, es más fácil buscar el elemento de código que queremos reescribir, porque entonces es la entidad propia sobre la que podemos actuar.
En este ejemplo, he utilizado una acción de reescritura para modificar la anotación. La reescritura es una acción de uso general que se puede aplicar a cualquier elemento del código y es una buena opción predeterminada para explorar.

Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez consulter le rapportVeuillez réserver une démonstration.Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
En esta entrada del blog, haremos lo siguiente:
- Demuestre la búsqueda y la coincidencia de anotaciones
- Anotaciones de amén con plantillas de bigote
Sensei brinda la capacidad de hacer coincidir patrones de código problemáticos y luego modificarlos para adaptarlos a las implementaciones acordadas. En este ejemplo, estoy usando @Disabled sin un parámetro como patrón de código problemático.
Anotación de prueba deshabilitada
Las pruebas deshabilitadas sin un motivo específico pueden resultar problemáticas a largo plazo porque olvidamos por qué las deshabilitamos.
@Disabled
void ThisTestMethodHasNoDisabledReason () {
Assertions.fail («Esta prueba está deshabilitada y no debe ejecutarse»);
}
El riesgo es que, con el tiempo, la base del código avance, la prueba deshabilitada no se actualice de acuerdo con el propósito del código y, finalmente, se vuelva redundante e irrelevante y, potencialmente, nunca se vuelva a habilitar.
Durante las revisiones del código, solemos señalar que es una buena idea añadir una descripción explicativa como parámetro de anotación.
@Disabled («Desactivado para demostrar la adición de un motivo»)
void ThisTestMethodHasDisabledReason () {
Assertions.fail («Esta prueba está deshabilitada y no debe ejecutarse»);
}
Una receta de Sensei
Podemos escribir una receta para detectar cuándo se añade @Disabled sin explicación y una solución rápida que nos recuerde que debemos añadir el motivo real que explica por qué lo hemos desactivado.
Cuando pienso en lo que voy a hacer, tengo que:
- coincide con la anotación deshabilitada sin ningún parámetro
- cambie la anotación deshabilitada para que tenga un parámetro con el texto de marcador «TODO: agregue una descripción aquí»
Crea una receta de advertencia
Utilizo Alt+Enter para crear una nueva receta.

A continuación, añada el texto descriptivo básico en la información general.

Al convertir la regla en una advertencia, cualquier código coincidente se resalta, pero no se muestra como un error evidente.

Encuentra la anotación
En el editor de recetas, cambio la búsqueda para que coincida con una anotación.
Esto resaltará todas las anotaciones en la vista previa.

Una vez hecho esto, quiero filtrar el tipo de anotación.
Podría usar Disabled, pero califico completamente la clase con el paquete para que solo coincida con la anotación de JUnit 5. Como el código fuente se muestra en la vista previa, puedo copiarlo y pegarlo fácilmente desde el código real para evitar errores tipográficos.
Luego quiero hacer coincidir solo las anotaciones sin parámetros, y puedo usar la GUI para hacerlo.

es decir, buscar:
buscar:
anotación:
tipo: «org.junit.jupiter.api.disabled»
sin:
parámetros:
- {}
Crear una acción de corrección rápida de reescritura
Para mi QuickFix usaré una acción de reescritura.
Yo uso el Mostrar variables funcionalidad para mostrarme las variables de Mustache y previsualizar el contenido.

Y luego agrego el código adicional necesario para crear el comentario del marcador de lugar.

es decir, QuickFix:
Correcciones disponibles:
- nombre: «Añadir un parámetro de comentario de todo»
acciones:
- reescribir:
to: «{{{.}}} (\" TODO: añade una descripción aquí\»)»
objetivo: «yo»
Sensei en acción
Hemos creado un breve vídeo que muestra el proceso de creación de recetas en acción.
Resumen
Al crear una solución rápida de reescritura, es más fácil buscar el elemento de código que queremos reescribir, porque entonces es la entidad propia sobre la que podemos actuar.
En este ejemplo, he utilizado una acción de reescritura para modificar la anotación. La reescritura es una acción de uso general que se puede aplicar a cualquier elemento del código y es una buena opción predeterminada para explorar.
Table des matières
Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour débuter
Thèmes et contenu de la formation sur le code sécurisé
Notre contenu de pointe évolue constamment afin de s'adapter au paysage changeant du développement logiciel, en tenant compte de votre rôle. Nous proposons des thèmes allant de l'IA à l'injection XQuery pour différents postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par thème et par fonction.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : les missions IA de Beat the Boss sont désormais disponibles à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année chez SCW. Mettez en œuvre des défis de sécurité avancés basés sur l'IA et le LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent se préparer grâce à des pratiques de conception sécurisées, à la prévention des vulnérabilités et au développement des compétences des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en 10 parties intitulée « Les catalyseurs de la réussite », qui montre comment relier la codification sécurisée aux résultats commerciaux, tels que la réduction des risques et la rapidité d'atteinte de la maturité du programme à long terme.




%20(1).avif)
.avif)
