Quand j'ai lu le code de test que j'ai écrit il y a quatre ans, j'ai réalisé que l'intention d'un certain code de test de Comparator était difficile à lire. Le contenu du test est correct, mais je ne pouvais pas imaginer un cas d'utilisation spécifique en lisant le test.
C'est un bon code de test dans une certaine mesure car il garantit l'exactitude du code du produit, mais si possible, il serait plus heureux que les responsables de la postérité puissent lire l'intention. Alors, j'ai trouvé un temps libre et j'ai essayé de le réécrire.
Dans cet article, nous allons présenter l'ancien code de test et le code de test amélioré, et l'utiliser comme service commémoratif.
public class TodayReportComparator implements Comparator<Report> {
@Override
public int compare(Report lhs, Report rhs) {
//Bonne chance
}
}
TodayReportComparator est un comparateur qui trie les rapports d'aujourd'hui afin de les hiérarchiser.
Commençons par le test conventionnel. Ce test vérifie le résultat de l'exécution de Comparator # compare.
public class TodayReportComparatorTest {
private TodayReportComparator sut;
@Before
public void setUp() {
sut = new TodayReportComparator();
}
@Test
public void Le rapport d'aujourd'hui vient en tête du rapport d'hier() {
final long now = System.currentTimeMillis();
lhs = new Report(new Date(now));
rhs = new Report(new Date(now - 24 * 60 * 60 * 1000));
assertThat(sut.compare(lhs, rhs), lessThan(0)); //lhs est élevé
}
@Test
public void Le rapport d'aujourd'hui vient en tête du rapport de demain() {
final long now = System.currentTimeMillis();
lhs = new Report(new Date(now));
rhs = new Report(new Date(now + 24 * 60 * 60 * 1000));
assertThat(sut.compare(lhs, rhs), lessThan(0)); //lhs est élevé
}
}
lhs, rhs) est utilisé et il ressemble à un test de comparaison.Collections.sort, mais aucun test n'est écrit dans ce cas d'utilisationEn tout cas, c'est une histoire dont vous devez vous souvenir du comportement de Java SE, ou vous pouvez l'imaginer avec un peu de réflexion. Mais du point de vue du critique, honnêtement, je ne veux pas trop utiliser mon cerveau.
Dans le test récemment réécrit, je me suis concentré sur ce que je voulais que le résultat de Collections.sort, qui est l'utilisation réelle, soit.
public class TodayReportComparatorTest {
private TodayReportComparator sut;
@Before
public void setUp() {
sut = new TodayReportComparator();
}
@Test
public void Le rapport d'aujourd'hui vient en tête du rapport d'hier() {
// Given
final long now = System.currentTimeMillis();
Report todayReport = new Report(new Date(now));
Report yesterdayReport = new Report(new Date(now - 24 * 60 * 60 * 1000));
List<Report> actual = Arrays.asList(
yesterdayReport,
todayReport
);
List<Report> expected = Arrays.asList(
todayReport, //Le rapport daté d'aujourd'hui est en haut
yesterdayReport
);
// When
Collections.sort(actual, sut);
// Then
assertThat(actual, is(expected));
}
@Test
public void Le rapport d'aujourd'hui vient en tête du rapport de demain() {
// Given
final long now = System.currentTimeMillis();
Report todayReport = new Report(new Date(now));
Report tomorrowReport = new Report(new Date(now + 24 * 60 * 60 * 1000));
List<Report> actual = Arrays.asList(
tomorrowReport,
todayReport
);
List<Report> expected = Arrays.asList(
todayReport, //Le rapport daté d'aujourd'hui est en haut
tomorrowReport
);
// When
Collections.sort(actual, sut);
// Then
assertThat(actual, is(expected));
}
}
Je l'ai écrit selon mes goûts actuels. Je pense que l’intention de «donner la priorité au rapport d’aujourd’hui et de l’évoquer» que j’ai voulu faire au départ peut être exprimée dans le test.
Actuellement, j'ai l'habitude d'écrire TDD en écrivant Java, et si je peux écrire un test, j'écrirai le test en premier.
Le code de test est utile non seulement pour l'exactitude du code produit, mais également pour exprimer et affiner la convivialité. Ce serait bien de pouvoir écrire du code de test qui aidera à améliorer le code du produit.
Recommended Posts