TDD : Irgendein Muster für konstante Tests?

Question

Konstanten sind wunderbare Menschen - sie können an einer einzigen Stelle einen Wert speichern, der überall in Ihrem Code verwendet wird. Das Ändern dieses Wertes erfordert nur eine einfache Änderung.

Das Leben ist cool.

Nun, das ist das Versprechen. Die Realität ist manchmal anders:

• Sie ändern die LogCompleteFileName konstanter Wert aus L:\LOGS\MyApp.log a \\Traces\App208.txt und Sie erhalten zwei Dateien : \\traces\App208.txt für die Spuren und \\traces\App208.txt.log für die Protokolle...
• Sie ändern TransactionTimeout von 2 auf 4 Minuten zu ändern, und Sie erhalten immer noch eine Zeitüberschreitung nach 2 Minuten (nachdem Sie den Tag damit verbracht haben, herauszufinden, dass Sie auch die Zeitüberschreitung des DBMS und die Zeitüberschreitung des Transaktionsmanagers ändern müssen...).
• Sie ersetzen SleepTimeInMinutes de 1 a 10 und Sie sehen keine Veränderung (nach etwa einer Stunde stellen Sie fest, dass der Name der Konstante irreführend war: die Granularität ist nicht die Minute, sondern die Millisekunde...).
• Noch subtiler: Sie ändern CompanyName von, sagen wir Yahoo a Microsoft aber automatische E-Mail-Benachrichtigungen werden immer noch gesendet an alert@yahoo.com ...

Die Erstellung einer Konstante ist ein Vertrag. Sie teilen Ihren Lesern mit, dass der Wert, wenn sie ihn ändern, immer noch so funktioniert, wie sie denken, dass er sein sollte.

Nicht weniger.

Natürlich müssen Sie prüfen, ob Sie Ihre Leser nicht in die Irre führen. Sie müssen sicherstellen, dass der implizierte Vertrag richtig ist.

Wie kann man das mit TDD erreichen? Damit komme ich einfach nicht weiter. Die einzige Möglichkeit, wie ich eine Änderung für einen konstanten (!) Wert testen kann, ist, diese Konstante zu einer Anwendungseinstellung zu machen... Sollte ich zu dem Schluss kommen, dass die const Schlüsselwort vermieden werden sollte, wenn ich denke, dass sich der Wert ändern kann und wird?

Wie testen Sie Ihre (so genannten) Konstanten mit TDD?

Vielen Dank im Voraus :)

Answer 1

Es hört sich für mich so an, als würden Sie Konstanten hauptsächlich zur Veranschaulichung von Konfigurationseinstellungen verwenden. Das ist ideal für den ConfigurationManager, aber auch für Tests kann dies schwierig sein.

Ich würde die folgende Verwendung empfehlen:

const String SomeValue = "TESTCONSTANT";

static class ConfigurationSettings
{
    static String SomeProperty
    {
        get
        {
           var result = SomeValue;
           if (ConfigurationManager.AppSettings["SOMEKEY"] != null)
               result = ConfigurationManager.AppSettings["SOMEKEY"];
           return result;
        }
    }
}

Answer 2

Wenn Sie einen Unit Test machen, glaube ich nicht, dass es etwas falsch mit so etwas ist:

[Microsoft.VisualStudio.TestTools.UnitTesting.TestMethod]
public void DefaultValue_Equals_8()
{
     Assert.AreEqual<int>(8, MyNamespace.MyClass.DefaultValue);
}

gegen die getestet wird:

namespace MyNamespace
{
    public class MyClass
    {
        public const int DefaultValue = 8;
    }
}

Dadurch wird festgestellt, ob die Konstante geändert wurde.

Der andere Teil Ihres Problems ist die Verwendung der Konstante durchgängig . Wenn Sie sie nicht überall, wo es notwendig ist, in der erwarteten Weise verwenden, dann verlassen Sie sich nicht auf Konstanten, sondern auf Berechnungen (oder magische Zahlen ).

Answer 3

Bei einigen der Beispiele handelt es sich eher um Konfigurationselemente als um Konstanten. In diesem Fall - auch wenn Sie kurzfristig Konstanten verwenden - sollten sie in den Bereich injiziert werden, in dem sie verwendet werden, und der Code sollte wie üblich getestet werden. Wenn der Wert zur Laufzeit nicht geändert werden kann, könnten Sie auch verwenden Sie einen Beispieltest um den Wert wie unten beschrieben.

Wenn Sie etwas testen, das wirklich eine Konstante ist (z. B. const FEET_PER_METRE = 3.28084 ), dann brauchen Sie nur einen Beispieltest zu haben, der sowohl die Berechnung als auch den Wert umfasst (die Daten dieses Tests sollten aus einer unabhängigen Quelle stammen, anstatt sie einfach selbst aus Ihrer deklarierten Konstante zu berechnen).

Assert.AreEqual<decimal>(29.5276, converter.metresToFeet(9))

Auf diese Weise erfüllt der Test zwei Zwecke:

1) Wenn sich herausstellt, dass Ihr Beispiel und Ihre Konstante falsch waren, können Sie Ihren Test mit einem korrekten Beispiel aktualisieren, einen fehlgeschlagenen Test erhalten und dann die Konstante korrigieren, damit sie grün wird.

2) Es bietet Sicherheit bei Regression. Wenn jemand versehentlich die Konstante ändert (z.B. den falschen Wert oder den Wert mit dem Finger verändert, während er etwas anderes in der Datei bearbeitet), dann wird er durch einen fehlgeschlagenen Test gewarnt.