Comment marquer du code qui doit être supprimé avant la production?

Les concepts d'inversion de TDD et de dépendance peuvent vous aider ici. En mettant le code qui varie en une classe qui implémente une interface, vous pouvez contrôler lorsque la version de test de ce code fonctionne et lorsque la version Prod est exécutée.

Ensuite, vous avez un fichier, clairement nommé comme étant pour tester, que vous pouvez laisser de votre construction.

J'essaierais d'éviter cela autant que possible. - une approche alternative consisterait à utiliser une injection de dépendance pour injecter des implémentations différentes pour les tests.

ou ...

ajoutez un champ booléen intesté aux objets et enveloppez le code facultatif dans une instruction IF. < / p> xxx

Vous pouvez définir cette injection de dépendance ou la lire à partir d'une propriété système transmise dans la propriété système (-DIntest = true)

espère que cela aide.

Vous pouvez utiliser un préprocesseur Java. Pour les applications J2ME, j'utilise le préprocesseur d'antenne. Le code ressemble à ce xxx

Évitez la nécessité. Si vous placez du code dans une classe qui ne devrait pas être là dans la production, déterminez comment procéder différemment. Fournissez un crochet, disons, de sorte que le code de test puisse faire ce dont il a besoin, mais laissez le code de test en dehors de la classe. Ou sous-classe pour tester ou utiliser une injection de dépendance ou toute autre technique qui laisse votre code valide et sans danger pour la production, tout en maintenant testable. Beaucoup de telles techniques sont bien documentées dans le livre fantastique de Michael Feathers, Efficacement avec le code hérité .

Eclipse permet d'ajouter d'autres marqueurs que simplement // TODO, vous pouvez ajouter, par exemple, // toBeramoved et lui donner une priorité élevée, il apparaît donc avant tous les autres marqueurs de TODO.

Le moyen évident de résoudre ce problème est d'avoir un test unitaire qui fonctionne uniquement sur la construction visant à créer les fichiers de production (ou de vérification si la version actuelle est ciblée pour la production et exécute le test si elle est) et échouer la construction si le test échoue.

Vous n'oublierez jamais. En ce qui concerne quel type de test, idéalement, il vérifierait réellement quel que soit le code. Si cela n'est pas possible, alors une statique mondiale en tant que Terry Lorber suggéré serait beaucoup mieux que ce que vous avez maintenant.

Il suffit d'ajouter // TODO: - Ensuite, faites un script C # (CS-Script.net) qui recherche // TODO dans votre code et les affiche. Vous pouvez ensuite ajouter ce script à vos constructions automatisées (si vous faites cela), donc chaque fois que vous faites une construction, vous pouvez voir ce qu'il y a à faire. Examinez la liste TODO de votre code avant de déployer.

Alternativement à écrire votre propre script, il existe des instructions sur la manière d'intégrer Vstudio avec un outil qui indique également vos lignes de Todo: http://predicateet.blogspot.com/2006/12/show-all-tasks-in-visual-Studion- 2005-C.HTML

Cependant, il me semble que la mise en place de cet outil est plus une douleur que d'écrire un script C # simple avec une regex.

Dans les projets que j'ai travaillé, j'ai eu diverses tarits de code qui sont en place pour permettre des tests faciles pendant le développement. Je les enveloppe dans un bloc IF qui vérifie une finale booléenne. Lorsque le booléen est vrai, le code peut être consulté. Lorsque le booléen est faux, je dépend du compilateur en supprimant le code des fichiers .Class résultants comme optimisation. Par exemple:

public class Test {
    public static void main(String[] args) {
        final boolean TESTABLE = true;

        if (TESTABLE) {
            // do something
        }
    }
}

Vous pouvez également définir simplement des marqueurs de commentaires de tâches plus forts: Fixme (priorité élevée) et XXX (priorité normale) sont standard dans Eclipse, et vous pouvez définir plus d'étiquettes de tâches (Eclipse Properties -> Java -> Compiler -> Tags de tâches)

Si vous souhaitez échouer votre construction, vous pouvez utiliser la fourmi (1.7) contient sélecteur de fichier pour rechercher des fichiers contenant du texte spécifié: xxx

évidemment, modifier $ {pom.build.sourcedirectory} à Votre répertoire source et fixme au commentaire que vous souhaitez rechercher.

Quelqu'un peut-il connaître une bonne façon d'imprimer les fichiers trouvés dans ce fichier de fichiers dans le fichier de construction ( autre que de regarder à nouveau dans l'éclipse)?