Ermüdet von nicht-semantischen Tests, um dynamische Typisierungsvorschläge wettzumachen?

Question

Ich habe früher viel Webprogrammierung in Rails (PHP davor) gemacht, bevor ich angefangen habe, Computertechnik zu studieren.

Seitdem habe ich viel in der Schule in C gearbeitet und einige persönliche Dinge in Objective-C (Mac-Zeug). Ich habe gelernt, statische Typisierung zu lieben.

Aber jetzt muss ich eine professionelle Webentwicklung (Freelancing) machen und habe Rails wieder abgeholt. Ich finde es wirklich ärgerlich, nicht-semantische Typprüfungen zu schreiben. Ich habe diese kostenlos von C- und Objective-C-Compilern bekommen. Ich habe es geliebt, Build zu treffen und das System alle meinen Code überprüfen zu lassen, um zu sehen, dass A B anrufen kann, B irgendeine obskure Bibliothek C usw. anrufen kann. Alles, was ich tun musste, war, die Semantik zu testen. Aber mit Rails bin ich der Compiler. :(

Hat jemand diesen gleichen Weg beschritten sind meine einzigen Optionen für Web-Entwicklung ASP.NET MVC mit C# und Java + x Rahmen für einige Vorschläge Sehen, oder sogar eine gewisse Sympathie ...?:? P

Übrigens, ich mache einen speziellen Verweis auf Rails und nicht auf Ruby, weil ich Rubys dynamische Natur für einfache Sachen wie Scripting oder was auch immer nicht mag, aber da Rails auf so viele Edelsteine ​​angewiesen ist und da man normalerweise eine Menge anderer Edelsteine ​​hinzufügt die dynamische Typisierung, wird ein Problem

Dank

edit:.!

Ich folgte auf Vorschlag von Pst und schaute in Scala. Als ich das Buch Programming in Scala las, geschrieben von dem Autor der Sprache, Martin Odersky, stieß ich auf diesen Text, der in vielerlei Hinsicht meine Bedenken und ein bisschen mehr ausdrückt. Sehr interessante Lektüre.

ab Seite Taken 52 von Martin Odersky der Programmierung in Scala:

Scala statisch

Ein statisches Typsystem klassifiziert Variablen und Ausdrücke nach die Arten von Werten eingegeben wird sie halten und berechnen. Scala ist eine Sprache mit einem sehr fortgeschrittenen statischen Typ System. Ausgehend von einem System von geschachtelten Klassen Typen wie Java, ermöglicht es Ihnen, Typen mit Generika zu parametrisieren, um Typen mit Kreuzungen zu kombinieren, und Details von Typen mit abstrakten Typen ausblenden. Diese geben eine starke Grundlage für den Aufbau und Komponieren Sie Ihre eigenen Typen, so dass Sie Schnittstellen entwerfen können, die bei gleichzeitig sicher und flexibel zu verwenden sind.

Wenn Sie dynamische Sprachen wie wie Perl, Python, Ruby oder Groovy, Sie könnte es ein wenig seltsam, dass Scala statischen Typ System als eine seiner Stärken aufgeführt ist. Nach alle, das Fehlen eines statischen Typs System wurde von einigen als Hauptvorteil der dynamischen Sprachen zitiert. Die häufigsten Argumente gegen statischen Typen sind, dass sie Programme zu ausführlich, verhindern Programmierer von sich selbst auszudrücken , wie sie wollen, und machen unmöglich bestimmte Muster dynamischer Modifikationen von Software-Systemen machen.

aber oft sind diese Argumente nicht gehen gegen die Idee der statischen Typen in allgemeinen, sondern gegen bestimmte Art Systeme, die wahrgenommen werden, zu ausführliche oder zu unflexibel zu sein. Für Beispiel, Alan Kay, der Erfinder der Smalltalk Sprache, einmal angemerkt: "Ich bin nicht gegen Typen, aber ich weiß nicht von Systeme, die keine komplette Schmerzen sind, so dass ich immer noch mag dynamische typing „

Wir hoffen, dass Sie in diesem Buch zu überzeugen dass Scala Typ-System weit von ist ein Wesen‚vollständiger Schmerz‘in der Tat, es Adressen schön zwei der üblichen Bedenken über statische Typisierung..: Ausführlichkeit wird durch Typ Inferenz vermieden und Flexibilität wird gewonnen durch Mustererkennung und mehrere neue Möglichkeiten zum Schreiben und Verfassen von Typen. Mit diesen Hindernissen aus dem Weg, die klassischen Vorteile der statischen Systeme können besser geschätzt werden. Zu den wichtigsten von diesen Vorteile sind überprüfbare Eigenschaften von Programm Abstraktionen, sichere Refactorings, und besser Dokumentation.

prüfbare Eigenschaften

Statische Typsysteme können die Fehlen bestimmter Laufzeitfehler beweisen. Zum Beispiel können sie Eigenschaften wie beweisen: booleans sind nie zu ganzen Zahlen hinzugefügt; auf private Variablen wird nicht von außerhalb ihrer Klasse zugegriffen; Funktionen werden auf die richtige Anzahl von Argumenten angewendet; Nur Strings werden jemals zu einem Satz von Strings hinzugefügt.

Andere Arten von Fehlern werden von heutigen statischen Systemtypen nicht erkannt. Für Instanz werden sie normalerweise keine nicht abschließenden Funktionen, Array Grenzen Verletzungen oder Divisionen von Null erkennen. Sie werden auch nicht erkennen, dass Ihr Programm nicht mit seiner Spezifikation übereinstimmt (vorausgesetzt, es gibt eine Spezifikation, das ist!). Statische Systeme wurden daher von einigen als nicht sehr nützlich abgetan. Das Argument geht, dass solche Typ Systeme nur einfache Fehler erkennen können, während Unit-Tests bieten umfangreichere Abdeckung, warum mit statischen Typen überhaupt kümmern? Wir glauben, dass diese Argumente den Punkt verfehlen.Obwohl ein statischer Typ System kann sicherlich nicht Einheit Tests ersetzen, kann es die Anzahl der Einheit Tests reduzieren, die durch die Pflege von einige Eigenschaften, die sonst müssen getestet werden müssen. Ebenso kann die Einheit Testen die statische Typisierung nicht ersetzen. Schließlich, wie Edsger Dijkstra sagte, Tests können nur das Vorhandensein von Fehler beweisen, nie ihre Abwesenheit. So garantiert die , dass statische Typisierung gibt kann einfach sein, aber sie sind echte Garantien einer Form keine Menge von Tests liefern kann.

Sicher Refactorings

Ein statisches Typsystem bietet ein Sicherheitsnetz, das Sie Änderungen mit einem hohen Maße an Vertrauen auf eine Code-Basis machen kann. Stellen Sie sich zum Beispiel ein Refactoring vor, das einen zusätzlichen Parameter zu einer Methode hinzufügt. In einer statisch typisierten Sprache können Sie die Änderung vornehmen, Ihr System neu kompilieren und einfach alle Zeilen beheben, die einen Typfehler verursachen. Sobald Sie damit fertig sind, haben Sie sicher alle Orte gefunden haben, die geändert werden müssen. Dasselbe gilt für viele andere einfache Refactorings wie Ändern eines Methodennamens oder Verschieben von Methoden von einer Klasse in eine andere. In alle Fälle eine statische Typüberprüfung bieten genug Sicherheit, dass das neue System funktioniert genau wie das alte.

Dokumentation

Statische Typen sind Programmdokumentation , die vom Compiler für Korrektheit überprüft. Im Gegensatz zu einem normalen Kommentar, eine Art Anmerkung kann nie aus dem Datum sein (zumindest nicht, wenn die Quelldatei , dass es vor kurzem einen Compiler übergeben enthält hat). Darüber hinaus können Compiler und integrierte Entwicklungsumgebungen Typ Anmerkungen verwenden, um bessere Kontexthilfe bieten. Für Beispiel eine integrierte Entwicklungsumgebung können alle Mitglieder für eine Auswahl von Bestimmung der statischen Typ der Ausdruck, auf dem die Auswahl alle Mitglieder diese Art hergestellt ist und Nachschlagen verfügbar angezeigt werden soll.

Answer 1

Dies ist einer meiner „gripes“ über dynamische Sprachen. Ich möchte auf Semantik testen, nicht auf Fehler ;-) Allerdings ist ein gutes Test-Framework/Setup in allen nicht-trivialen Situationen ein Muss und gute Code-Coverage und getestete Anforderungen sind wichtig.

Wenn Sie den statischen Schreibpfad auf der JVM (ich habe) gehen wollen, würde ich empfehlen, Scala zu betrachten. Von Ruby kommend, ist es viel weniger schmerzhaft (und eigentlich viel Spaß auf verschiedene Arten), als nach Java zu gehen. Sie können die Dinge, die Sie für selbstverständlich halten, "behalten" - eine ausdrucksbasierte Syntax, Closures, die Möglichkeit, Typen an vielen Stellen wegzulassen (nicht so offen wie Ruby, aber Sie bekommen eine Typüberprüfung zur Kompilierung ;-), alles (*) - ist-an-Objekt OO, einheitliche Zugriffsmethoden, die Fähigkeit, DSLs leicht zu konstruieren und Zucker - und die Vorteile eine statisch typisierten Sprache mit lokaler Typinferenz, pattern-Matching, ein relativ reichen Sammlung Rahmen erhalten, und Anständige Integration mit Java (einschließlich der zahlreichen Web-Frameworks, es gibt auch einige Scala-spezifische Frameworks, die die Scala-Sprache nutzen).

C# 3.0/4.0 (und .NET3.5 +) ist nicht zu schäbig entweder (aber vermeiden C# 2.0, die jetzt hoffentlich ein Relikt ist), mit der Einführung von LINQ/Verschlüsse, Grundtyp Inferenz und andere nette Sprachfunktionen Ich finde es "akzeptabel" für die meisten Aufgaben (Raten Sie, wie ich Java als Sprache bewerten würde ;-). C# ist jedoch eine CLR-Zielsprache (es gibt/war ein .NET Scala-Port, aber ich bin mir des Status nicht sicher - es ist jedoch nicht die Hauptzielplattform).

Da ich Scala erwähnt habe, sollte ich auch F # erwähnen (jetzt eine "offizielle" .NET-Sprache), die den "Functional with OO" -Ansatz ähnlich wie OCaml nimmt - Scala ist eher das Gegenteil und ich würde beschreiben es als "OO mit Funktional". Ich habe Argumente für/gegen F # im Vergleich zu C# w.r.t des Typsystems gehört, aber habe keine praktische Erfahrung mit F #. Sie mögen oder mögen den Paradigmenwechsel nicht.

Glückliche Kodierung.

Answer 2

Diese Art von Tests wird normalerweise nicht in Rails durchgeführt. Anstatt sich darüber ärgern zu müssen, sollten Sie sich keine Sorgen machen. Oder vielleicht besser erklären, warum Sie denken, dass es ein Problem ist, da die meisten Rails-Programmierer dies nicht tun.

aktualisiert

Die Person, die test_include_with_order_works schrieb sicher macht, dass Rails ein Symbol das gleiche wie eine Zeichenfolge in diesem speziellen Fall interpretiert. Das scheint nicht etwas zu sein, was Sie testen müssten, da Rails diese Funktionalität bereits für Sie bereitgestellt und getestet hat.Ehrlich gesagt bin ich ein wenig überrascht, dass sich irgendjemand darüber Gedanken machen würde, ob ein Symbol wie eine Schnur funktioniert oder nicht. Wir alle wissen, dass es das kann und oft tut.

Generell denke ich, dass das Rails-Framework Dinge zu gewährleisten, die Sie nicht so, dass seine Umsetzung seiner Konstruktion entsprechen wird. Ich glaube, dass die Arbeitsphilosophie in dynamisch typisierten Sprachen darin besteht, dass Client-Code keine Parameter übergibt, die die Methoden, die sie aufrufen, durchbrechen. Wenn sie das tun, nutzen sie die Methoden nicht aus. Sie müssen nicht Ihre Zeit verschwenden, indem Sie sicherstellen, dass Ihre Methoden Ausnahmen auslösen, wenn zu viele Parameter bereitgestellt werden, wenn Ihre Methode die zusätzlichen Parameter ebenso leicht ignorieren kann (und sollte).

Also, ich bin nicht sicher, ob die Beispiele, die Sie wirklich die Notwendigkeit einer nicht-semantischen Tests in Rails demonstrieren zur Verfügung gestellt haben.

Answer 3

Wie Sie erwähnen Rails, und da Sie in Scala zu interessieren, sollten Sie auf jeden Fall Lift überprüfen. Hier ist ein 2008 interview mit seinem Schöpfer und ein 2009 presentation (Video), die ich verbinden, weil sie zwar alt, sie Lift Alternativen in anderen Sprachen vergleichen.

Wenn Aufzug ist nicht Ihr Ding, aber seien Sie versichert, dass es other Scala web frameworks sind.