7
votes

Un test d'unité doit-il compter sur des constantes définies par l'application?

Considérez le pseudocode suivant. Il est conçu pour déterminer si une note est une note de passage.

ensure that IsStudentPassing is false when grade is 69
ensure that IsStudentPassing is true when grade is 70


0 commentaires

3 Réponses :


0
votes

Comme j'ai toujours essayé de fonctionner dans le passé: des tests d'unités doivent vérifier toutes les conditions de limite possibles / test de contrainte une fonction ou un sous-ensemble spécifique de la fonctionnalité du tout, et qu'une plus grande suite de régression devrait tester l'ensemble du programme de validité de le côté de l'entreprise.

Par conséquent, dans votre exemple, le premier test serait dans mes tests unitaires et le second dans ma régression.

Je suis un nouveau venu relatif de l'industrie, cependant, et j'aimerais savoir si je ne suis pas sur la bonne voie.


0 commentaires

1
votes

Par préférence, vous injecteriez la valeur "constante" avec l'une de vos propres conceptions, de sorte que votre test de l'unité soit isolé des aléas de quoi, en fait, constitue une note de passage. Quelle est facile à faire varie selon le langage de programmation. Considérez ce code pour une langue qui facilite la tâche:

use MooseX::Declare;
class Student {
    has grade => (
        is => 'ro', isa => 'Num', required => 1,
    );

    method min_passing_grade {
        return MIN_PASSING_GRADE;
    )

    method is_student_passing () {
        return $self->grade >= $self->min_passing_grade
    }
}

class t::Student {
    use Test::Sweet;
    use Test::MockObject::Extends;

    test correctly_determines_student_is_passing () {
        my $student = $self->_make_student($self->_passing_grade);

        ok($student->is_student_passing);
    }

    method _make_student (Num $grade) {
        my $student = Test::MockObject::Extends->new(
            $student->new(grade => $grade)
        );
        # Here's the important line:
        $student->set_always(
            min_passing_grade => $self->_passing_grade
        );
        return $student;
    }

    method _passing_grade () { 40 }

    test correctly_determines_student_is_failing () {
        my $student = $self->_make_student($self->_passing_grade - 1);

        ok(not $student->is_student_passing);
    }
}


0 commentaires

1
votes

La préférence ne serait pas d'utiliser une constante du tout, mais faites-en une propriété d'une interface qui est transmise. C'est ainsi que des travaux d'injection de dépendance (qui aident à leur tour TDD).

Vous utiliseriez ensuite un cadre test (ou moqueur) pour générer les tests. N.b. Vous voulez probablement tester plus que quelques valeurs de chaque côté de la valeur cible. Vous voudrez également tester les limites du type de données pour piéger les erreurs de débordement / sousflage.


0 commentaires