master > master: codego initialisiert
This commit is contained in:
64
codego/README.md
Normal file
64
codego/README.md
Normal file
@@ -0,0 +1,64 @@
|
||||
# Code in golang #
|
||||
|
||||
Die Inhalte dieses Ordners sind absolut **kein Pflichtbestandteil** des Kurses.
|
||||
|
||||
Diese dienen nur zur Demonstration / konkreten Verwirklichung von Verfahren, die im Kurs auftauchen. Für Wissbegierige mit auch grundlegenden Programmierkenntnissen bietet sich dies als Möglichkeit an, um sich selbst zu überzeugen, dass strukturelle Rekursion funktioniert.
|
||||
|
||||
Der Gebrauch dieser Skripte unterliegt der Eigenverantwortung von Studierenden.
|
||||
|
||||
Da ich kein Informatiker bin, sind auch einige Aspekt bestimmt nicht optimal programmiert/strukturiert.
|
||||
|
||||
## Systemvoraussetzungen ##
|
||||
|
||||
- bash (auch bash-for-windows).
|
||||
- golang (mind. 1.6.x)
|
||||
|
||||
## Voreinstellungen ##
|
||||
|
||||
- In einer bash-console zu diesem Ordner navigieren und folgenden Befehl ausführen:
|
||||
```bash
|
||||
chmod +x run.sh test.sh
|
||||
## oder
|
||||
chmod +x *.sh
|
||||
```
|
||||
- In `run.sh` gibt es eine Zeile, die zur Kompilierung des Go-Projektes notwendigen Module über **go** installieren lässt. (Die Liste der Packages findet man in der Datei `requirements`). Diese Zeile kann man ruhig nach der ersten Ausführung rauskommentieren.
|
||||
|
||||
## Daten ##
|
||||
|
||||
In `data.env` kann man Daten (aktuell: auszuwertenden Ausdruck + Interpretation/Modell) eintragen. Man beachte dabei die Syntax.
|
||||
|
||||
## Gebrauchshinweise ##
|
||||
|
||||
In einer bash-console zu diesem Ordner navigieren und
|
||||
```bash
|
||||
./run.sh
|
||||
## oder
|
||||
go build main.go && ./main
|
||||
```
|
||||
ausführen.
|
||||
|
||||
## Offene Challenges ##
|
||||
|
||||
In der Datei `aussagenlogik/rekursion.go` (relativ zu diesem Ordner) findet man mehrere leere Methoden (mit dem Kommentar `// Herausforderung...`). Wer es mag, kann versuchen, an seinem Rechner diese Methoden zu definieren und auszuprobieren.
|
||||
|
||||
### Händisch testen ###
|
||||
|
||||
Probiere es mit Stift-und-Zettel und anhand von Beispielen die Werte händisch zu berechnen. Vergleiche dies mit den durch den Code rekursiv berechneten Werten. Stimmt alles überein?
|
||||
|
||||
### Automatisierte Tests ###
|
||||
|
||||
Wer etwas standardisierter seine Methoden testen will, kann automatisiertes Testing tätigen. Diese Tests existieren parallel zu jedem Modul und folgen dem Namensschema `..._test.go`.
|
||||
|
||||
- In der Console (wenn noch nicht geschehen) folgenden Befehl einmalig ausführen:
|
||||
```bash
|
||||
chmod +x test.sh
|
||||
```
|
||||
- In `aussagenlogik/rekursion/rekursion_test.go` beim relevanten Testteil eine oder mehrere der Zeilen
|
||||
```go
|
||||
test.Skip("Methode noch nicht implementiert")
|
||||
```
|
||||
rauskommentieren/löschen.
|
||||
|
||||
Jetzt `test.sh` ausführen. Die unittests testen Methoden gegen mehrere vorkonstruierte Testfälle samt erwarteten Ergebnissen geprüft. Sollten einige Tests scheitern, dann Fehlermeldung durchlesen, und Methode entsprechend der Kritik überarbeiten.
|
||||
|
||||
Die geschriebenen Unittests sind natürlich nicht ausführlich. Man kann diese nach Bedarf ergänzen. Am sinnvollsten baut man welche, die wirklich scheitern können, sonst sagen die Tests nichts aus.
|
||||
Reference in New Issue
Block a user