KIF410:Arbeitskreise

Bitte erfindet neue Arbeitskreise, oder führt Projekte vergangener KIFs weiter. Jeder kann einen AK vorschlagen und auf dem Anfangsplenum vorstellen.

Inhalt- und Arbeits-AKs

Für eher ernsthafte Arbeitskreise, -kringel und -punkte ist dieser Abschnitt da.

Bezeichnung	Wer macht's?	Wie viele?	Wann?	Dauer?
AK Free Software	slowpoke	Egal	Termin?	Zeitumfang
Beschreibung: Der Einsatz und die Foerderung Freier Software in Lehre, Forschung und Alltag ist mir persoenlich ein wichtiges Anliegen, dass ich speziell an der Universitaet vorantreiben moechte. Ich wuerde gerne diskutieren, austauschen und auch Leute an die durchaus komplexe Thematik heranfuehren, die im Bereich Informatik im speziellen und ander Uni im allgemeinen meiner Meinung nach nicht genug Beachtung findet. Der AK hat ansonsten (noch) keine konkrete Zielsetzung - Vorschlaege willkommen.
[ eingebundene Seite bearbeiten ] eingebunden aus KIF410:AK Free Software : Diskussionsvorschläge Software von/für Lehrstühle unter freie Lizenzen stellen Wie überrede ich den Professor (Argumente sammeln) Verlauf/Ergebnisse Es gab einige Teilnehmer, denen das Prinzip von Freier Software erklärt wurde. Generell finden alle Teilnehmer, dass es eine gute Idee ist, die Nutzung und das Entwickeln von Freier Software in Forschung und Lehre zu fördern. Es gibt einige Hochschulen, an denen der Einsatz bereits gut funktioniert (in Lehre und Forschung), und die auch selbst Freie Software entwickeln. Auf der anderen Hand gibt es Hochschulen (scheinbar hauptsächlich mit stark Wirtschaftsnaher Ausrichtung), bei denen so gut wie ausschliesslich proprietäre Software eingesetzt wird. Dies ist nach Aussagen der dort studierenden auch vorraussichtlich schwer zu ändern. Es wird festgestellt, dass viele Studierenden, die mit Softwareentwicklung zu tun haben, wenig bis keine Ahnung von Lizenz- und Urheberrecht haben. Keine anwesende Hochschule hat dies als Teil der entsprechenden Veranstaltungen. Die Anwesenden sind sich einig, dass dies nach Möglichkeit geändert werden sollte, eventuell erst durch Veranstaltungen ausserhalb der Vorlesungen.
Softwaretests für Anfänger und Fortgeschrittene	Franzi & JanS	So viele wie in einen Rechnerraum passen (2 pro Rechner)	egal	2 x 2h
Beschreibung: Auf der letzen KIF habe ich gemerkt, dass ein großes Interesse daran besteht zu lernen, wie man gute Softwaretests schreibt. Dieser AK setzt sich aus Theorieteilen und praktischen Übungen dazu zusammen. Ich brauche daher einen Rechnerraum - niemand sollte einen Laptop mitbringen müssen. Der AK findet in zwei Teilen statt, so dass Menschen mit ein bisschen Vorwissen zu JUnit etc. sich im ersten Teil nicht langweilen und Menschen ohne Vorkenntnisse erst ein mal abgeholt werden.
[ eingebundene Seite bearbeiten ] eingebunden aus KIF410:Softwaretests für Anfänger und Fortgeschrittene : AK Softwaretest Testzyklus Roten Test schreiben, der eine noch fehlende Funktionalität abzudecken (d.h. Test schlägt noch fehl) Implementieren, bis der Test grün ist Refaktorisieren, Test bleibt grün Nächsten Test schreiben, der wiederum rot ist Arten von Tests Unit Test: Test einer möglichst kleinen Softwareeinheit, typischerweise unabhängig von den anderen, z.B. einer einzelnen Klasse oder Methode. Davon gibt es viele. Test soll möglichst wenige Abhängigkeiten haben, z.B. möglichst nicht auf Datenbank zugreifen Integrationstest: Zusammenspiel zwischen den Einheiten bzw. Testen der Schnittstellen. Es gibt weniger Integrationstests als von den Unit Tests. Akzeptanztest: Test, der prüft, ob Kundenanforderungen erfüllt sind. Muss nicht funktional sein, sondern kann auch z.B. ein Performancetest sein. Kann auch manuell erfolgen, was aber teuer ist und dann nur stichprobenartig testen sollte. Smoketest/Anlauftest: Anfrage gegen die Software bzw. das System werfen und schauen, ob sie abstürzt bzw. nen Fehler wirft. UI Test: Test der Anwendbarkeit der Oberfläche: Kommen alle Knopfdrücke richtig in der Business Logic an? - Nicht versuchen, damit alle Funktionalität abzuprüfen. Regressionstest: Test, der sicherstellt, dass eine Neuerung keine Funktionalität verliert im Vergleich zur alten Version - sowohl funktional als auch nichtfunktional. Mutation Test: Werkzeug, das automatisch Code kaputtmacht, und prüft ob dann auch ein Test fehlschlägt. Whitebox-/Blackboxtest: Test, der "weiß", wie einzelne Komponenten implementiert sind, bzw. der das nicht weiß. Fuzzy Test/Monkey Test: Zufällige Erzeugung von Input und Test, wie Software reagiert bzw. welche Pfade sie durchläuft. Was macht einen guten Test aus? Fast: Er läuft in kurzer Zeit durch (z.B. Unit Tests: max. 30 Sekunden, Integrationstest: max. 10 Minuten) Independent: Er ist unabhängig von anderen Methoden. Schlägt er fehlt, sollte das nicht dazu führen, dass andere auch fehlschlagen. Repeatable: Beinhaltet genug Eingangsdaten, um jederzeit alleinstehend wiederholbar zu sein. Small: Er ist spezifisch, d.h. nur auf einen Aspekt des Programms bezogen Transparent: Es ist aus dem Code/der Doku hinreichend klar, was der Test macht und warum er fehlschlägt, wenn er fehlschlägt. Vorgehen Positiv- und Negativtests Vom Einfachen zum Schwierigen gehen Äquivalenzklassen bilden und diese gemeinsam testen Grenzfälle abdecken Arrange: Datenstrukturen initialisieren Act: Aktion ausführen Assert: Prüfen, ob Ergebnis korrekt ist/den Anforderungen entspricht Akzeptanztests "Wann bin ich mit dem Implementieren fertig?" Ich bin fertig, wenn der Kunde zufrieden ist und alle seine Anforderungen erfüllt wurden (und er keine weiteren hat). Akzeptanztests müssen zeigen, dass bei richtiger Eingabe auf der Schnittstelle zum Benutzer/Kunden das Richtige herauskommt und bei falscher Eingabe eine entsprechende Behandlung erfolgt. Sie sollten unabhängig von der Implementierung sein. Formulierungsformen: "Wenn (Ereignis), dann (Effekt), sonst (Effekt)." "Wenn (Voraussetzung) und dann (Ereignis), dann soll (Effekt), sondern (Effekt)." Wichtig: Akzeptanztests müssen vollständig sein, sonst kann man sie gleich weglassen. Aus Akzeptanztests kann man auch Regressionstests machen, z.B. für den Fall, dass man nach längerer Zeit, in der man sich nicht mit dem Code beschäftigt hat, noch ein Feature hinzufügen will. Fixture Bestandteile Set Up: Voraussetzungen schaffen, z.B. Datenstrukturen initialisieren Exercise: Tests ausführen Verify: Ergebnis prüfen Tear Down: Ursprungszustand des Systems wiederherstellen, z.B. Seiteneffekte des Tests rückgängig machen Arten Fresh Fixture: Vor jedem Test baut die Fixture die benutzten Daten neu auf Shared Fixture: Die Fixture baut die Daten einmal auf und benutzt sie dann für alle Tests. Problem: Tests könnten Daten verändern Ausweg: Shared Mutable Fixture Stubs Beispiel Master Mind: Um eine Spieler-KI dafür zu testen, möchte man nicht gegen das "echte" Master Mind testen, sondern z.B. gegen Stubs Stubs: Erbt von der ursprünglichen Klasse, überlagert nur die für den Test interessanten Methoden z.B. reagieren immer gleich, egal was für ein Input kommt Dummy: Gibt bei allen Methoden nur einen statischen wert zurück Fake: Klasse, die nur so tut, als ob sie z.B. eine Datenbankverbindung aufbaut, aber in Wahrheit Werte stattdessen aus einer Hashtable zieht Mock: Implementiert bzw. erweitert ursprüngliche Klasse nicht, sondern benutzt ein Mocking Framework

Kultur- und Spaß-AKs

Kulturelle und freizeitgestaltende Arbeitskreise der KIF. Da Spaß auf einer KIF kultiviert wird und damit eine eigene Kultur bildet, gehören Spaß-AKs ebenfalls in diese Tabelle.

Bezeichnung	Wer macht's?	Wie viele?	Wann?	Dauer?
DIE Reso	Julius	Alle	von Anfang an	true
Beschreibung: Die alle Probleme der Welt löst.
[ eingebundene Seite bearbeiten ] eingebunden aus KIF410:DIE Reso :