Est-il jamais autorisé de ne pas tester une fonctionnalité?

Y a-t-il un moment où vous devenez si familier avec votre langue / base de données / système qu'il n'est pas nécessaire de tester une nouvelle fonctionnalité / configuration / requête / etc. par des tests contenus / simulés avant de les implémenter dans votre système (notamment concernant une fonctionnalité qui modifie les données)? Ou est-il toujours indispensable de tester une nouvelle requête par simulation dans un environnement de test ?

Pour préciser davantage, il est clair qu'il est toujours plus sûr de tester. Cependant, existe-t-il un moyen de déterminer quand le risque est si minime que les tests n'en valent pas la peine? Une autre façon de formuler cela: quand ou est-ce une pratique professionnelle de prendre un risque mesuré pour implémenter une fonctionnalité?

Supposons également que tout soit sauvegardé, donc, dans le pire des cas, les données pourraient être restaurées avec un certain effort.

Quelqu'un peut-il citer une expérience spécifique et experte pour résoudre ce problème? Veuillez inclure des références lorsque cela est approprié / possible.

Je veux commencer par dire que tout ce que je fais est SQL Server, donc ce sont les exemples que je donne. En général, cependant, cela s'applique à toute forme de code, quel que soit le système.

Commençons par décomposer un peu.

Mises à jour

Vous avez un système et vous êtes sur le point de le mettre à niveau en partie ou en totalité. Par exemple, la mise à niveau d'une instance de SQL Server 2012 vers 2014. À ce stade, les tests sont essentiels. Malheureusement, tester toutes les parties d'une même petite application ne sera probablement pas possible. À ce stade, je ferais ce que j'appellerais un test "de travail". Le système de base fonctionne-t-il? Parcourez vos tâches courantes du début à la fin. Ne testez pas toutes les options, juste le chemin principal.

Lors de la mise à niveau de SQL Server, une lecture est également requise . Fondamentalement, vous voulez lire l' Backward Compatibilityentrée de la nouvelle version ( voici celle de 2014 ) et vous assurer que vous n'avez rien dans aucune des listes (changements de rupture, changements de comportement, etc.).

Code d'application

Ici, nous examinons le code d'application nouveau / changeant (car bien sûr, tout ce qui existe a déjà été testé, n'est-ce pas?). Dans ce cas, tout doit être testé. Vous devriez avoir des cas de test configurés à l'avance et exécuter au moins la majorité des fonctionnalités concernées. De préférence, à ce stade, vous devriez également demander à quelqu'un d'autre de faire une vérification similaire. Ce code va être en place, probablement pendant assez longtemps, et utilisé par un grand nombre de personnes. Vous voulez vous assurer que cela fonctionne et fonctionne bien.

L'une des choses qui peut vraiment aider à cela est de générer un ensemble de ce unit testsqui est facilement reproductible. Steve Jones recommande d' utiliser tSQLt pour tester votre code TSQL (SQL Server uniquement, je le crains). Mais en faisant cela, vous pouvez exécuter rapidement un ensemble fixe de tests et cela facilitera vraiment les tests de régression (tout tester, par exemple avant de faire une mise à niveau).

Caractéristiques / configurations

Encore plus que les changements de code d'application, vous voulez tester en profondeur les nouvelles fonctionnalités et les changements de configuration. Si, par exemple, vous décidez de commencer à travailler avec des index columnstorepour la première fois, vous devrez tester chaque morceau de code qui touche les tables affectées. Utilisez les tests unitaires que vous avez générés pour tester votre application. Ces fonctionnalités sont probablement nouvelles pour vous (et peut-être nouvelles dans la plate-forme) et comporteront probablement des problèmes auxquels vous ne vous attendiez pas. En ce qui concerne les changements de configuration, vous parlez de quelque chose qui peut affecter l'ensemble de votre système, éventuellement de manière significative. La règle de base est de tester et de tester soigneusement. Il y a des changements que vous ne verrez vraiment que lorsque vous entrerez dans un système actif (peut-être uniquement votre système de production), mais ce n'est pas une excuse pour ne pas les essayer dans un environnement de test en premier.

Requêtes ad hoc qui référencent / affectent les données utilisateur

Lorsque vous avez du code qui affecte vos données utilisateur, vous devez généralement le tester, même et peut-être surtout parce qu'il l'est Ad Hoc. Cela étant dit, si vous exécutez le même morceau de code, encore et encore, juste avec des paramètres différents, vous n'avez probablement pas à vous soucier des tests à chaque fois.

Par exemple, vous devez supprimer une ou plusieurs annonces du tableau AdList chaque trimestre.

DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')

À ce stade, vous avez déjà testé le code (vous changez simplement des chaînes fixes) et vous êtes probablement assez en sécurité en exécutant le code (en supposant que vous ayez de bonnes sauvegardes au cas où).

Un moyen simple de tester un DELETE, UPDATEou INSERTde les changer en SELECT et de les exécuter, puis de confirmer que le nombre et le type de lignes attendus sont retournés.

Vous pourriez penser que vous n'avez pas besoin de tester les SELECTs car ils ne modifient en fait aucune donnée. Cependant, vous exécutez le code pour une raison non? Supposons que vous effectuez des recherches pour votre responsable, qui à son tour remettra ces données à son responsable, etc. Vous testez pour vous assurer que vous n'obtenez pas les mauvaises données (ou que vous empêchez les autres de collecter leurs données).

Requêtes ad hoc qui référencent / affectent les données système

C'est peut-être la seule exception à la règle "Tout tester". Vous exécutez des requêtes d'informations sur les données système. L'important ici est de récupérer les données que vous attendez. Si la requête est quelque chose de simple (interrogation d'une vue système), vous êtes probablement d'accord tant que vous avez vérifié la signification réelle de la vue / des colonnes. Si la requête est complexe (par exemple, frapper 3 ou 4 vues système avec des calculs sur les colonnes renvoyées), vous voudrez peut-être exécuter quelques tests juste pour vous assurer que vous allez récupérer les données que vous attendez.

Sommaire

En résumé, oui, vous voulez tout tester. Si c'est assez important pour que vous l'écriviez et l'exécutiez, alors c'est assez important pour que vous puissiez le tester. Cela ne signifie cependant pas que vous devez passer énormément de temps à tester chaque branche de chaque ligne de code. Mais un certain niveau de test doit être fait.

Le test unitaire automatisé est votre ami ici. Avec l'avènement de DevOpset Continuous Integrationvous verrez de plus en plus d'applications et de méthodes pour tester rapidement et facilement votre code. Bien sûr, cela nécessite d'avoir un bon environnement de test et des données pour l'accompagner, mais c'est une toute autre discussion.

Je sais ce que vous ressentez, j'ai 3 ans de travail avec MySQL, et dans mon cas, je teste toujours les requêtes DML qui peuvent modifier ou casser n'importe quelle information sur chaque table / base de données / réplication esclave.

C'est toujours le moyen le plus sûr de tester votre requête avant de l'exécuter.

Il n'y a aucun moyen de savoir si votre requête peut mettre en danger vos informations de données. La seule façon est de connaître la structure et la configuration de votre base de données, de sorte que vous puissiez facilement identifier le moment où une requête pourrait mettre vos données sensibles en danger ou non.

Sur DELETE, UPDATE, INSERT, vous devriez toujours essayer d'utiliser d' SELECTabord si vous n'êtes pas sûr de ce que les informations que vous allez modifier. Sur les sélections, essayez toujours d'utiliser le même type de données pour les conditions que le type de données de la colonne, dans certains cas, utilisez EXPLAINpour l'optimisation.