[JAVA] Implementierung von FizzBuzz-Problemen in der testgetriebenen Entwicklung (Vorbereitung)

Zunächst möchte ich Testcode schreiben ... aber vorher muss ich bestätigen, dass JUnit korrekt installiert ist.

Bereiten Sie insbesondere die Testklasse FizzBuzzTest.java vor, schreiben Sie ein leeres Testprogramm und führen Sie den Test aus.

Erstellen von FizzBuzzTest.java

Bereiten Sie zunächst die Testklasse wie folgt vor.

1. Setzen Sie den Cursor auf "src / __ test__ / java" und klicken Sie mit der rechten Maustaste auf> Neu-> Paket
2. Geben Sie einen beliebigen Paketnamen in das Feld Name ein und klicken Sie auf Fertig stellen
3. Setzen Sie den Cursor auf das erstellte Paket, klicken Sie mit der rechten Maustaste -> klicken Sie auf Klasse
4. Geben Sie FizzBuzzTest in das Feld Name ein und klicken Sie auf Fertig stellen (andere Einstellungen bleiben bei ihren Standardeinstellungen).

Die Projektstruktur nach dem Erstellen von FizzBuzzTest.java lautet wie folgt.

Erstellen Sie ein leeres Testprogramm

Implementieren Sie als Nächstes eine leere Testmethode, die in der erstellten Datei FizzBuzzTest.java nichts bewirkt.

FizzBuzzTest.java

import org.junit.Test;

public class FizzBuzzTest {
    @Test
public void JUnit-Betriebstest() {
        
    }
}

Testlauf

Platzieren Sie den Cursor auf der JUnit-Operationstestmethode der von Ihnen erstellten FizzBuzzTest-Klasse und klicken Sie mit der rechten Maustaste auf> Ausführen als-> JUnit-Test, um den Test auszuführen.

Dann sehen Sie einen grünen Balken, der anzeigt, dass der Test erfolgreich war, wie in der folgenden Abbildung gezeigt.

Dies zeigt, dass JUnit standardmäßig arbeitet und JUnit verwenden kann. Wenn der Test hingegen fehlschlägt, können Sie Fehler in der Testumgebung feststellen. Beispielsweise war die Maven-Installation nicht erfolgreich.

Nachdem Sie bestätigt haben, dass JUnit einwandfrei funktioniert, ist die ** Vorbereitung ** beendet.

Hier werde ich die endgültige Projektstruktur und den Programminhalt mit den Worten "Fazit kommt zuerst" veröffentlichen. [^ 3]

Projektstruktur

Testprogramm

FizzBuzzTest.java

package com.example;

import static org.junit.Assert.assertEquals;

import org.junit.Test;
import org.junit.experimental.runners.Enclosed;
import org.junit.runner.RunWith;

@RunWith(Enclosed.class)
public class FizzBuzzTest {

public static class Argument ist kein Vielfaches von 3 und 5{
        FizzBuzz fizzbuzz = new FizzBuzz();

        @Test
public void Gibt 1 zurück, wenn 1 als Argument angegeben wird() {
            assertEquals("1", fizzbuzz.response(1));
        }
    }
    
öffentliche statische Klasse Ein Vielfaches von 3 mit nur 3 Argumenten{
        FizzBuzz fizzbuzz = new FizzBuzz();

        @Test
public void Gibt Fizz mit 3 Argumenten zurück() {
            assertEquals("Fizz", fizzbuzz.response(3));
        }
    }

öffentliche statische Klasse Ein Vielfaches von 5 mit nur 5 Argumenten{
        FizzBuzz fizzbuzz = new FizzBuzz();

        @Test
public void Gibt Buzz mit 5 Argumenten zurück() {
            assertEquals("Buzz", fizzbuzz.response(5));
        }
    }

öffentliche statische Klasse Argumente sind Vielfache von 3 und 5{
        FizzBuzz fizzbuzz = new FizzBuzz();

        @Test
public void Gibt FizzBuzz mit 15 Argumenten zurück() {
            assertEquals("FizzBuzz", fizzbuzz.response(15));
        }
    }
    
Das öffentliche statische Klassenargument ist ein gültiger Grenzwert{
        FizzBuzz fizzbuzz = new FizzBuzz();
        
        @Test
public void Gibt 1 zurück, wenn Argument 1 angegeben ist() {
            assertEquals("1", fizzbuzz.response(1));
        }

        @Test
public void Gibt Buzz mit 100 Argumenten zurück() {
            assertEquals("Buzz", fizzbuzz.response(100));
        }
    }

Das öffentliche statische Klassenargument ist ein ungültiger Grenzwert{
        FizzBuzz fizzbuzz = new FizzBuzz();
        
        @Test(expected = IndexOutOfBoundsException.class)
public void Ein Fehler tritt auf, wenn das Argument 0 angegeben wird.() {
            fizzbuzz.response(0);
        }

        @Test(expected = IndexOutOfBoundsException.class)
Ein öffentlicher void-Fehler tritt auf, wenn das Argument 101 angegeben wird() {
            fizzbuzz.response(101);
        }
    }
}

Zu testendes Programm

FizzBuzz.java

public class FizzBuzz {

    public String response(int num) {
        StringBuilder result = new StringBuilder();
        
        if(num < 1 || num > 100) {
            throw new IndexOutOfBoundsException();
        }
        
        if(num % 3 == 0) {
            result.append("Fizz");
        }

        if(num % 5 == 0) {
            result.append("Buzz");
        }
        
        if(result.length() == 0) {
            result.append(String.valueOf(num));
        }

        return result.toString();
    }
}

Das nächste Mal möchte ich als ** Übung ** veröffentlichen, wie ich mit der Implementierung der folgenden Testklasse (FizzBuzzTest.java) und der Testzielklasse (FizzBuzz.java) fortgefahren bin.

Referenz

• [Amazon \ .co \ .jp: [Verständnis in diesem einen Buch] Softwaretest Lehrbuch-Grundlagen und Praxis des Testprozesses, der die Qualität bestimmt eBook: Kazuhiro Ishihara, Hidekazu Tanaka, Masashi Tanaka: Kindle Store](https :: //www.amazon.co.jp/%E3%80%90%E3%81%93%E3%81%AE1%E5%86%8A%E3%81%A7%E3%82%88%E3%81 % 8F% E3% 82% 8F% E3% 81% 8B% E3% 82% 8B% E3% 80% 91% E3% 82% BD% E3% 83% 95% E3% 83% 88% E3% 82% A6 % E3% 82% A7% E3% 82% A2% E3% 83% 86% E3% 82% B9% E3% 83% 88% E3% 81% AE% E6% 95% 99% E7% A7% 91% E6 % 9B% B8_% E5% 93% 81% E8% B3% AA% E3% 82% 92% E6% B1% BA% E5% AE% 9A% E3% 81% A5% E3% 81% 91% E3% 82 % 8B% E3% 83% 86% E3% 82% B9% E3% 83% 88% E5% B7% A5% E7% A8% 8B% E3% 81% AE% E5% 9F% BA% E6% 9C% AC % E3% 81% A8% E5% AE% 9F% E8% B7% B5-% E7% 9F% B3% E5% 8E% 9F-% E4% B8% 80% E5% AE% 8F-ebook / dp / B00U17809A / ref = sr_1_1? ie = UTF8 & qid = 1496770784 & sr = 8-1 & keywords =% E3% 82% BD% E3% 83% 95% E3% 83% 88% E3% 82% A6% E3% 82% A7% E3% 82% A2% E3% 83% 86% E3% 82% B9% E3% 83% 88% E3% 81% AE% E6% 95% 99% E7% A7% 91% E6% 9B% B8)

• Lesen Sie "Warum die meisten Unit-Tests nicht helfen"|Entwicklungsmethode / Projektmanagement| POSTD

• Testgetriebene Entwicklung in 50 Minuten / TDD Live in 50 Minuten // Speaker Deck

• Was ist testgetriebene Entwicklung, warum gefällt sie Ihnen, warum sollten Sie sie auch verwenden?|Entwicklungsmethode / Projektmanagement| POSTD

• Fizz \ -Was ist das Buzz-Problem? \ -Hatena-Schlüsselwort

[^ 1]: Ich habe nur die Zusammenfassung gelesen, aber die ursprüngliche Geschichte lautet [Warum \ -Most \ -Unit \ -Testing \ -is \ -Waste \ .pdf](http://rbcs-us.com/ Dokumente / Warum-die-meisten-Unit-Tests-sind-Abfall.pdf) Es ist geschrieben in.

[^ 2]: Wenn beispielsweise in einem Filmreservierungssystem mit mehreren Rabattoptionen gemäß den Benutzereigenschaften die letzte Anforderung "die Option anwenden, die den Rabattsatz erhöht" lautet, wird aus der Bedingung der Benutzereigenschaften heraus, dass der Rabattsatz hoch ist Ich werde es testen.

[^ 3]: Es gibt einige Unterschiede zur Live-Codierung in de: code, auf die ich mich bezog, da dies das Ergebnis meiner eigenen Praxis war und einige Teile aus zeitlichen Gründen in de: code weggelassen wurden.