Zur Erinnerung:
Ich überschreibe den Hashcode einiger meiner großen Objekte, um ihn für Unittests zu benutzen. Der ursprüngliche Hashcode ist dafür unbrauchbar, da er anscheinend nur die Speicheradresse des Objekts umformt (kann man leicht testen, indem man das Programm verschiedene Male aufruft). Damit der neue Hashcode für Unittests zu gebrauchen ist, muss ich natürlich wissen, wann er vom jeweiligen Rechenlauf abhängt und wann er unveränderlich ist.
Der Suchbaum einer Branch-and-Bound-Suche nach 20 Suchschritten. So ein B&B-Suchbaum kann nicht nur sehr groß sein, sondern hat auf jedem seiner Knoten auch noch verschachtelte Listen und massenweise andere Attribute. So ein Suchbaum ist natürlich nur ein Zwischenergebnis zur Lösung der Aufgabe, aber für meine Unittests muss ich gerade die Zwischenergebnisse überprüfen, da die Endlösung viel zu wenig über den Code eines einzelnen Moduls aussagt.mutetella hat geschrieben:Kannst Du mir vielleicht einmal ein konkretes Beispiel eines solchen Objektes oder eines seiner Attribute geben?
Bei so langen Berechnungen sollte man den Test vielleicht nicht Unittest, sondern "Pakettest" nennen. Ich kenne das richtige Ergebnis nicht und dessen Berechnung ist bei weitem zu lang, um sie von Hand durchzuführen. Ich habe also kaum eine Alternative. Bei Diskrepanzen müssen die Fehler sowohl beim alten als auch wie beim neuen Code gesucht werden; das verdoppelt die Arbeit. Aber es ist weniger dramatisch als es aussieht, da man den Pakettest bei jeder Codeänderung aufruft und der Fehler oft (leider nicht immer) mit der letzten Änderung zu tun hat.anogayales hat geschrieben:Was machst du wenn der Unit Test fehlschlägt? Dann weißt du ja nur, dass es irgendwo eine Diskrepatz gibt, aber nicht notwendigerweise wo. Bei einer so großen Menge an Daten wird dir das doch wenig weiterbringen, oder?