On peut tester les procédures SQL, qui ont des paramètres d'entrée 
Après, j'ai aussi des SQL qui sont des requètes "à préparer", là effectivement leur test ne pourrait se faire que couplé à un driver client, mais je peux les transformer en procédures aussi.
Je ne comprends pas la question sur le retour: le SQL peut te retourner des résultats, donc tu les vérifies directement au lieu de les traiter pour ensuite en vérifier le traitement. En SQL pur, cela pourrait ressembler à CREATE TEMPORARY TABLE `mes_resultats`(...) puis INSERT INTO `mes_resultats` VALUES (.../*ce que j'attends comme sortie*/...); et enfin SELECT * FROM (.../*Ma requête à tester*/...) AS t OUTER JOIN `mes_resultats` AS mr ON mr.*=t.* /*pseudo-syntax*/ (y'a surement d'autres techniques pour propres pour checker qu'un jeu de résultats est strictement égal à un autre).
A mon avis, je vais effectivement finir sur un PHPUnit classique. Je pourrai même envisager de benchmarker différentes queries pour vérifier leur efficacité.
Après, j'ai aussi des SQL qui sont des requètes "à préparer", là effectivement leur test ne pourrait se faire que couplé à un driver client, mais je peux les transformer en procédures aussi.Je ne comprends pas la question sur le retour: le SQL peut te retourner des résultats, donc tu les vérifies directement au lieu de les traiter pour ensuite en vérifier le traitement. En SQL pur, cela pourrait ressembler à CREATE TEMPORARY TABLE `mes_resultats`(...) puis INSERT INTO `mes_resultats` VALUES (.../*ce que j'attends comme sortie*/...); et enfin SELECT * FROM (.../*Ma requête à tester*/...) AS t OUTER JOIN `mes_resultats` AS mr ON mr.*=t.* /*pseudo-syntax*/ (y'a surement d'autres techniques pour propres pour checker qu'un jeu de résultats est strictement égal à un autre).
A mon avis, je vais effectivement finir sur un PHPUnit classique. Je pourrai même envisager de benchmarker différentes queries pour vérifier leur efficacité.