[ALG] Unit Tests: vereist voor veiligheid of niet? *

[Alarmnummer]

Dit topic is afgesplitst van: [rml][ disc] Features voor in een veilige webserver[/rml]

Verwijderd schreef op 22 augustus 2004 @ 17:28:
[...]
Onzin, kwestie wat weten wat je doet en elke buffer goed controleren.

Maar gebruik je nu wel of geen unit tests in je systeem?

Als je dat niet hebt... dan heb je per definitie geen veilige server.

[ Voor 17% gewijzigd door gorgi_19 op 22-08-2004 19:34 ]

[Verwijderd]

Alarmnummer schreef op 22 augustus 2004 @ 17:32:Maar gebruik je nu wel of geen unit tests in je systeem?

Waarschijnlijk niet op de standaard manier, maar ja, ik test alle procedures. Is UnitTests ook eigenlijk niet meer iets voor OO talen? Hiawatha is namelijk in C gebouwd.

Als je dat niet hebt... dan heb je per definitie geen veilige server.

Niet per definitie. Er zijn meerdere manieren om veilige software te maken.

[ Voor 3% gewijzigd door Verwijderd op 22-08-2004 17:42 ]

[Alarmnummer]

Verwijderd schreef op 22 augustus 2004 @ 17:41:
[...]
Waarschijnlijk niet op de standaard manier, maar ja, ik test alle procedures. Is UnitTests ook eigenlijk niet meer iets voor OO talen? Hiawatha is namelijk in C gebouwd.
[...]
Niet per definitie. Er zijn meerdere manieren om veilige software te maken.

Als er maar een manier is om de functionaliteit op een geautomatiseerde manier te controleren. Als ik bezig ben met een systeem worden alle testen meerdere keren per dag gedraait. Ik gebruik het al een aantal jaren en ik pak er zo`n lading met kleine bugs mee uit mijn systeem dat ik het niet eens meer aandurf om een productie systeem zonder unittests te maken.

Mijn huidige prologcompiler+abstract machine heeft voor iedere regel code ook bijna een regel unit test code.

[ Voor 6% gewijzigd door Alarmnummer op 22-08-2004 17:51 ]

[Verwijderd]

Alarmnummer schreef op 22 augustus 2004 @ 17:45:
Als er maar een manier is om de functionaliteit op een geautomatiseerde manier te controleren.

En ik test mijn code op een niet-geautomatiseerde manier.

Maar we dwalen weer af van het onderwerp....

[Soultaker]

Alarmnummer schreef op 22 augustus 2004 @ 17:32:
Als je dat niet hebt... dan heb je per definitie geen veilige server.

Jij verdient een gouden medaille voor het onderdeel naar conclusies springen (excuseer het anglicisme).

Een formeel bewijs lijkt me bijvoorbeeld een stuk betere garantie van veiligheid dan een paar unit tests. Ik wil daarmee niet zeggen dat unit tests nutteloos zijn, maar de conclusie dat een webserver zonder unit test suite per definitie onveilig is is net zo onzinnig als de conclusie dat een programma geschreven in C buffer overruns moet bevatten.

[Alarmnummer]

Verwijderd schreef op 22 augustus 2004 @ 17:52:
[...]

En ik test mijn code op een niet-geautomatiseerde manier.

Maar we dwalen weer af van het onderwerp....

Absoluut niet. Een ketting is zo sterk als zijn zwakste schakel en 1 fout is voldoende om van jouw fort een tent te maken. Daarom zijn unit testen imho ook zo belangrijk. Dan kan je de 'domme' fouten er een beetje snel uitpakken. En die zitten gewoon in je systeem (zeker in een taal zoals c omdat je daar een redelijk ruime syntax hebt en met pointers kan pielen). Echt veilige systemen worden tegenwoordig allemaal geschreven in save languages zoals Java.

[Alarmnummer]

Soultaker schreef op 22 augustus 2004 @ 17:55:
[...]

Jij verdient een gouden medaille voor het onderdeel naar conclusies springen (excuseer het anglicisme).

Een formeel bewijs lijkt me bijvoorbeeld een stuk betere garantie van veiligheid dan een paar unit tests. Ik wil daarmee niet zeggen dat unit tests nutteloos zijn, maar de conclusie dat een webserver zonder unit test suite per definitie onveilig is is net zo onzinnig als de conclusie dat een programma geschreven in C buffer overruns moet bevatten.

Misschien is per definitie dan een klein beetje overdreven.

Maar
-mijn gok is dat 99.99999999% van de c programma`s niet volledig formeel worden bewezen.
-met formele bewijzen pak je typefouten er niet uit.

Dus in de praktijk durf ik de stelling wel aan dat een programma zonder unit tests per definitie onveilig is.

[edit]
Het wel dus niet zeggen dat een programma met unit testen wel veilig is! Maar in ieder geval wel een stuk veiliger.

[ Voor 14% gewijzigd door Alarmnummer op 22-08-2004 18:14 ]

[Verwijderd]

Alarmnummer schreef op 22 augustus 2004 @ 17:55:
[...]

Absoluut niet. Een ketting is zo sterk als zijn zwakste schakel en 1 fout is voldoende om van jouw fort een tent te maken. Daarom zijn unit testen imho ook zo belangrijk. Dan kan je de 'domme' fouten er een beetje snel uitpakken. En die zitten gewoon in je systeem (zeker in een taal zoals c omdat je daar een redelijk ruime syntax hebt en met pointers kan pielen). Echt veilige systemen worden tegenwoordig allemaal geschreven in save languages zoals Java.

Oh ja, Java. Da's een goed gestuctureerde taal. Vandaar de garbage-collector.....

Maar als mijn webserver zo onveilig is, hack me dan! Bij deze daag ik je uit om aan te tonen dat mijn webserver onveilig is. Je hebt zelfs de beschikking over de source code. Zo niet, zullen we dan weer terug gaan naar het onderwerp?

[Alarmnummer]

Verwijderd schreef op 22 augustus 2004 @ 17:59:
[...]
Oh ja, Java. Da's een goed gestuctureerde taal. Vandaar de garbage-collector.....

Hmm tja.. je komt met dit soort opmerkingen niet echt serieus over.

Maar als mijn webserver zo onveilig is, hack me dan!

Mijn kennis over c is behoorlijk ver weggezakt dus ik ben helemaal niet de aangewezen persoon om bugs in jouw systeem op te sporen.

Bij deze daag ik je uit om aan te tonen dat mijn webserver onveilig is. Je hebt zelfs de beschikking over de source code. Zo niet, zullen we dan weer terug gaan naar het onderwerp?

Het onderwerp is een veilig webserver en dat is precies hetgene waar ik een opmerking over maak.

Als je serieus software leert ontwikkelen zul je zien dat unittesten een crusiaal onderdeel zijn

[Verwijderd]

Radiant schreef op 22 augustus 2004 @ 18:01:
Misschien een feature om bepaalde User-Agent's te blokkeren (download accelerators enzo)?

Is op zich makkelijk te klussen, maar wat is precies het doel van het blokkeren van bepaalde user-agents? Ik vraag me namelijk af of dit een veel gebruikte feature zal zijn en of het dus thuishoort in een webserver. Het is namelijk net zo makkelijk in een download script te klussen.

@Alarmnummer: ik ben ondertussen al 2 jaar bezig met deze webserver. Ik ben nu op een punt aangekomen dat ik durf te garanderen dat de server veilig is. Dat zeg ik niet zomaar. Ik ben het met je eens dat testen belangrijk is, begrijp me niet verkeerd. Maar dat heb ik naar mijn idee dus al genoeg gedaan. Als je me niet gelooft, ga je gang en lever me een tegen-bewijs. Graag zelfs!

En nogmaals: de reden van dit topic is omdat ik graag wil weten welke security-features men mist in bestaande webservers. Zullen we het daarbij houden?

[ Voor 39% gewijzigd door Verwijderd op 22-08-2004 18:26 ]

[DanielB]

IMHO is het nooit te garanderen dat een server volledig veilig is...

[Verwijderd]

DanielB schreef op 22 augustus 2004 @ 18:31:
IMHO is het nooit te garanderen dat een server volledig veilig is...

Dat mag je van mij denken, maar dat is niet waar.

[Alarmnummer]

Verwijderd schreef op 22 augustus 2004 @ 18:21:
[...]
@Alarmnummer: ik ben ondertussen al 2 jaar bezig met deze webserver.
Ik ben nu op een punt aangekomen dat ik durf te garanderen dat de server veilig is. Dat zeg ik niet zomaar. Ik ben het met je eens dat testen belangrijk is, begrijp me niet verkeerd. Maar dat heb ik naar mijn idee dus al genoeg gedaan.

Als je al 2 jaar geen regel meer hebt verandert.. en 2 jaar lang alle onderdelen van je systeem hebt getest (wat al lastig is.. zelfs met unit testen)., dan mag je daar een bepaalde zekerheid uit halen. Maar ik denk niet dat dat het geval is.. jij maakt continu nieuwe componenten er bij, past oude aan... refactored wat. Zo gauw dit het geval is, maak je gewoon fouten. Misschien had je je verstand er niet bij, was je moe, zat je met 1 oog tv te kijken en met de ander te programmeren.. fouten maak je gewoon.. en met unit testen kan je een gedeelte van dit soort fouten eruit vissen.

Je maakt de test eenmalig, maar je kan hem keer op keer draaien. Dat is een van de krachten van unit testen.

En nogmaals: de reden van dit topic is omdat ik graag wil weten welke security-features men mist in bestaande webservers. Zullen we het daarbij houden?

Probeer jezelf geen vals gevoel van zekerheid te geven door het test aspect te negeren. Ik durf te wedden dat als jij gaat unit testen, dat je er nog genoeg bugs uit gaat pakken. Ik zal er verder ook geen woorden meer aan vuil maken..

[ Voor 5% gewijzigd door Alarmnummer op 22-08-2004 18:59 ]

[gorgi_19]

Eigenlijk zonde om trouwens dat hele unit-test gedeelte om zeep te helpen; vandaar een afsplitsing Wel geldt: gaarne vriendelijk

Origineel topic: [rml][ disc] Features voor in een veilige webserver[/rml]

Ow, als mensen trouwens een betere titel weten, ik hou me aanbevolen

[ Voor 13% gewijzigd door gorgi_19 op 22-08-2004 19:39 ]

[Verwijderd]

Veiligheid van wat? Een unit test controleerd niet wat de inhoud is van input, alleen hoe deze is opgebouwd/gedefinieerd.

Ik denk dat je als test case best een server als IIS kunt pakken, dit soort stukken software worden echt wel aan zware tests onderworpen, en desondanks zijn er gaten.

[Infinitive]

Alarmnummer schreef op 22 augustus 2004 @ 17:58:
[...]
-met formele bewijzen pak je typefouten er niet uit.

Hoewel het miereneuken is, moet ik plichtshalve zeggen dat dit niet waar is

Ik neem aan dat je een "tiepfout" bedoeld (niet dat dat echt uitmaakt). We praten over een formeel bewijs. Dat heeft als eigenschap dat elke stap verifiëerbaar is door een automatische stellingchecker en een bewijs is pas een bewijs als het de stelling aantoont en door de checker heenkomt.

Stel dat er een tiepfout in het programma (of bewijs) zit en dat het door de checker heen komt. Dan is het bewijs geldig. Dan is het programma geldig. Ofwel, de tiepfout kan niet voorgekomen hebben (of is niet relevant).

Formeel bewijs van programma's is een heel gedoe

[Alarmnummer]

Verwijderd schreef op 22 augustus 2004 @ 19:38:
Ik denk dat je als test case best een server als IIS kunt pakken, dit soort stukken software worden echt wel aan zware tests onderworpen, en desondanks zijn er gaten.

Het is ook zeker geen garantie dat je programma bugvrij is. Maar je kan er wel bugvrijere programma`s door krijgen. Als je een unit test maakt kan je de testen eindeloos blijven herhalen. De meeste systemen die ik schrijf worden (als ik er mee bezig ben) meerdere malen per dag volledig geunit test. De unit test is vaak de enigste target die ik uitvoer als ik aan het developen ben.

Het heeft ook voordelen buiten de bugvrijere code om. Je krijgt over het algemeen herbruikbaardere code omdat je je code testbaar gaat maken. Dus ipv een hele zwik afhankelijkheden, kom je bij het unit testen er snel achter dat dat niet prettig werkt -> je verwijdert de afhankelijkheden en je introduceert bv mock objecten -> je ontwerp wordt meestal wat beter.

En verder zijn er een hele kluit mensen die geloven in TDD (Test Driven Development). Laat de unit testen bepalen wat je code precies moet gaan doen. In sommige gevallen kan dit handig zijn, maar heb er persoonlijk nog niet echt veel mee geexperimenteerd. Een ander voordeel aan TDD is dat al je code meteen voorzien is van testen. Unit testen zijn trouwens wel een ideale manier om de grenzen van je functies te verkennen. En zijn in sommige opzichten betere documentatie dan geschreven (passieve) documentatie.

Het ligt er bij mij heel erg aan wat ik aan het doen ben. Als ik aan het prototypen ben of me gewoon ergens een beeld van probeer te vormen (en niets helpt zo goed als een paar regeltjes code imho), dan heb ik geen zin aan unit testen. Dan zijn ze een enorm blok aan je been. Maar op het moment dat het een systeem gaat worden dat in een productie omgeving gaat draaien... dan ga ik grondig unit testen (moet in de toekomst nog wat grondiger mbt threading ed).

[edit]
Unit testen zijn ook ideaal om subsystemen te testen die in principe alleen binnen een volledig systeem kunnen draaien. Je krijgt dan een stuk vertrouwen in een systeem en je weet dat je daar niet zo snel naar bugs hoeft te zoeken. Niets is zo irritant om tig systemen door te moeten struinen op zoek naar een bug.

[ Voor 16% gewijzigd door Alarmnummer op 22-08-2004 20:01 ]

[whoami]

Unit tests zijn een manier om je systeem robuuster te maken.
Het consequent testen van je classes/modules na een build is gewoon een manier om fouten in je software sneller op te sporen.

Door te unit-testen op een geautomatiseerde manier kan je gewoon veel beter en sneller eventuele fouten opmerken. Het kan daarnaast ook een bewijs zijn dat je subsysteem/class doet wat ze moet doen.

[Infinitive]

Ik onderken de voordelen van unit testing. Echter, als ik aan unit tests denk, dan denk ik meer aan tests die controleren of het systeem werkt voor veel voorkomende input. Misschien dat je een paar randgevallen test, maar in principe wil je aantonen dat je systemen blijven functioneren en daarvoor gebruik je real-life data.

Beveiligingsproblemen zijn juist uitzonderingen. Uitzonderingen die bovendien ook geen echte randgevallen zijn. Deze situaties worden dus niet bedekt door je unit tests!

[whoami]

Infinitive schreef op 22 augustus 2004 @ 20:14:
Ik onderken de voordelen van unit testing. Echter, als ik aan unit tests denk, dan denk ik meer aan tests die controleren of het systeem werkt voor veel voorkomende input. Misschien dat je een paar randgevallen test, maar in principe wil je aantonen dat je systemen blijven functioneren en daarvoor gebruik je real-life data.

Die unit-tests voer je uit voor reguliere input, maar ook voor grensgevallen.
Ik denk dat meerdere mensen al eens aangetoond hebben dat een doorgedreven toepassen van unit-tests tijdens het ontwikkelproces tot betere software , tot een beter eindproduct kan leiden.

[ Voor 16% gewijzigd door whoami op 22-08-2004 20:18 ]

[Alarmnummer]

Infinitive schreef op 22 augustus 2004 @ 20:14:
Ik onderken de voordelen van unit testing. Echter, als ik aan unit tests denk, dan denk ik meer aan tests die controleren of het systeem werkt voor veel voorkomende input.

Ook voor de minder vaak voorkomende input. Jij moet in principe voor alle data (dat voor het testen interessant is) een test maken. Het maakt dus niet uit of iets wel of niet vaak voorkomt.

Misschien dat je een paar randgevallen test, maar in principe wil je aantonen dat je systemen blijven functioneren en daarvoor gebruik je real-life data.

Het voordeel van een test die je kan aansturen vanuit je software is dat je je systeem in een toestand kan zetten die je irl niet snel zou tegenkomen. Een goeie unit tests is gemaakt om de het systeem vast te laten lopen. Jij moet dus proberen om je systeem om zeep te helpen.

Beveiligingsproblemen zijn juist uitzonderingen. Uitzonderingen die bovendien ook geen echte randgevallen zijn. Deze situaties worden dus niet bedekt door je unit tests!

Hoe bedoel je?

[edit]
Unit testen zijn ook niet 'de' oplossing om bugs uit je programma te halen, het is gewoon een stuk beter dan niets. Niemand gaat volledig correctheidsbewijzen van programma`s, zeker niet als je bv 50.000 regels code in je systeem hebt zitten.

[ Voor 12% gewijzigd door Alarmnummer op 22-08-2004 20:29 ]

[whoami]

Trouwens, je kan in je unit-test toch al gaan testen op zaken zoals buffer overruns enzo als je een beetje goeie input-data kiest.

[Soultaker]

Een van de sterkste argumenten tegen unit tests (en bijna alle vormen van testen, trouwens) vind ik nog altijd dat ze geschreven worden door de programmeurs die ook de applicatie schrijven. Het is naar mijn ervaring lastig om unit tests te verzinnen waarvan je niet meteen weet wat je bestaande code ermee doet. Dat reduceert unit tests enigzins tot wat progession testing en regression testing. Hoewel regression testing op zichzelf best nuttig is, helpt het je niet veel bij het ontwikkelen van nieuwe code.

Misschien zou het schelen als je netjes eerst je interfaces definieert, dan je units tests schrijft, en daarna pas aan de implementatie begint. Je hebt dan immers je interface netjes gespecificeerd en kunt objectief testen of je implementatie eraan voldoet. Het nadeel je alleen die aspecten meeneemt die binnen jouw mindset passen blijft echter aanwezig, denk ik.

Andere vormen van testen, zoals draaien met profilers en debuggers, hebben die problemen niet, maar ze bestrijken ook een wat ander gebied (en ze hebben meestal ook invoer nodig, wat hetzelfde probleem oplevert). Toch denk ik dat je eerder een buffer overrun of iets dergelijks vind met een memory debugger dan met een unit test case. In Java is dat punt sowieso niet aan de orde want daar zijn veel fouten met betrekkingen tot geheugenbeheer simpelweg uitgesloten door de runtime environment.

[Orphix]

Ik zie unit testen meer als een controle die ervoor zorgt dat je programmatuur ook na wijzigingen op alle functionele gebieden correct gedrag blijft vertonen.
Er zit wel een addertje onder het gras. De unit-testen worden vaak geschreven door de programmeur van die code. Die zal dus enkel testen schrijven die hij van belang ziet. Dit zal zeker de bugs eruit halen die 'duidelijk' zijn, maar juist de complexere bugs of exploits zal je niet kunnen testen.

Stel dat het IE team ActiveX functionaliteit test. Een AX-control in een bepaalde veiligheidszone mag bijvoorbeeld niet de harde schijf benaderen. Dit wordt getest, en werkt. Echter nu blijkt dat wanneer geluid wordt afgespeelt in die ActiveX je via de thread die het geluid afspeelt wel de harde schijf kan benaderen. OK, dit is misschien een vergezocht hypothetisch geval. Maar wat ik wil zeggen is dat de combinatie van elementen nog steeds tot een onveilige omgeving kan zorgen.

Desalniettemin vind ik unit testen een erg goede programmeer tool en draagt het zeker bij aan hoe robuust je applicatie is en hoeveel vertrouwen je erin hebt. Maar dat dit automatisch tot veiligheid leidt, nee dat denk ik niet.

[alienfruit]

Het gebruiken van unit tests is er niet het middel om een programma veilig te maken, waarom denk je dat een Q&A meer geld verdient dan ene software architect bij bedrijven als Microsoft en Borland? Juist omdat hun zorgen voor de kwaliteitbewaking, ontwikkeling van testcases met specialitische tools (software van Mercury bijv. usability, regression, and black box testing e.d. allemaal ook erg belangerijk) natuurlijk is unit testing handig voor het testen of veranderen niet een averechts effect hebben e.d. Ik gebruik iig niet alleen unit testing.

Overigens heeft unit testing geen enkele zin, als je brakke tests schrijft. unit testing werkt alleen maar als je goede tests kan schrijven, en dat kan nog best wel lastig zijn. Liefst zou ik dan ook door een extern persoon willen laten doen.

[ Voor 28% gewijzigd door alienfruit op 22-08-2004 22:01 ]

[Alarmnummer]

alienfruit schreef op 22 augustus 2004 @ 21:57:
Het gebruiken van unit tests is er niet het middel om een programma veilig te maken, waarom denk je dat een Q&A meer geld verdient dan ene software architect bij bedrijven als Microsoft en Borland? Juist omdat hun zorgen voor de kwaliteitbewaking, ontwikkeling van testcases met specialitische tools (software van Mercury bijv. usability, regression, and black box testing e.d. allemaal ook erg belangerijk) natuurlijk is unit testing handig voor het testen of veranderen niet een averechts effect hebben e.d. Ik gebruik iig niet alleen unit testing.

De grens tussen integration en unit testen is bij mij heel vaag. Een methode call op 1 nivo is een compleet subsysteem op een ander. Onder unit testen versta dus ook het integration testen.


Verder is blackbox (net zoals whitebox) niet zozeer een volledige testmethode, maar een bepaalde techniek. Met blackbox testen mag je geen rekening houden met de interne werking van het te testen component, met whitebox juist wel.

Overigens heeft unit testing geen enkele zin, als je brakke tests schrijft. unit testing werkt alleen maar als je goede tests kan schrijven, en dat kan nog best wel lastig zijn. Liefst zou ik dan ook door een extern persoon willen laten doen.

Er is een groot verschil tussen schoolbank kennen en real live kennis. Waar ik nu werk hebben we niet genoeg personeel om zo te gaan specialiseren en ik denk dat dit voor heel veel bedrijven zo is. Unit testen is niet de pretigste oplossing, en als je je ze schrijft dan heb je soms ook het gevoel niet vooruit te komen. Soms vormen ze zelfs een blok aan je been omdat je niet alleen een systeem moet refactoren maar ook nog eens de unit tests. Maar toch merk ik iedere keer weer.. na verloop van tijd besparen ze me tijd... ik heb meer vertrouwen in mijn systeem en dat maakt mij een tevredener programmeur.

[ Voor 9% gewijzigd door Alarmnummer op 22-08-2004 22:55 ]

[NaliXL]

Kan iemand mij een beetje vertellen wat jullie precies verstaan onder "Unit testing"? Is dat gewoon om ieder geschreven stuk code een ander stuk code schrijven om te testen? Zo ja, dan heb je toch ook een enorm risico dat de test-code zelf bugs bevat, of dat de test-code niet test op de (door jou als programmeur niet ingecalculeerde) onverwachte situatie?

Ik hoor hier ook mensen roepen over "geautomatiseerd" unit testen praten: hoe werkt dat? Waarmee doe je dat?

[Alarmnummer]

Cherub schreef op 22 augustus 2004 @ 22:26:
Kan iemand mij een beetje vertellen wat jullie precies verstaan onder "Unit testing"? Is dat gewoon om ieder geschreven stuk code een ander stuk code schrijven om te testen? Zo ja, dan heb je toch ook een enorm risico dat de test-code zelf bugs bevat, of dat de test-code niet test op de (door jou als programmeur niet ingecalculeerde) onverwachte situatie?

Yep.. helemaal mee eens. Maar het is geen argument om te zeggen: doe het dan maar niet.

(achterlijk simpel voorbeeld unit test)

Java:

class PlusTestCase extends TestCase{
      public void test_1_1(){
            int result = 1+1;
            assertEquals(2,result);
      }
}

Maar het kan natuurlijk ook wat complexer:
(Een testsuite om een stackframe (in Prolog heet het een EnvironmentFrame) te testen)

Java:

public class EnvFrameTestSuite {

    public static TestSuite suite() {
        TestSuite suite = new TestSuite("EnvFrame TestSuite");
        suite.addTestSuite(BindTestCase.class);
        return suite;
    }

    public static class BindTestCase extends TestCase {

        private AbstractMachine _machine;
        private EnvFrame _frame;

        public BindTestCase(String fixture) {
            super(fixture);
        }

        public void setUp() throws AbstractMachineInitializeException {
            KnowledgebaseImpl kb = new KnowledgebaseImpl();
            _machine = new AbstractMachine(kb);
            _frame = _machine.getEnvFrameStack().peek();
        }

        public void testInitialStateRootFrame(){
            assertEquals(Frame.ENV,_frame._type);
            assertSame(_machine,_frame._machine);
        }

        //todo: initialStateNormalFrame

        //todo:restore

        //todo:snapshot.

        public void testBindPermanent() {
            int oldTrailSize = _machine._varTrailStack.size();

            Variable a = new Variable(0, "A");
            Term aValue = new IntConstant(10);
            _frame.bind(a, aValue, true);

            assertEquals(aValue, _frame.get(a));
            assertEquals(oldTrailSize, _machine._varTrailStack.size());
        }

        public void testBindNotPermanent() {
            int oldTrailSize = _machine._varTrailStack.size();

            Variable a = new Variable(0, "A");
            Term aValue = new IntConstant(10);
            _frame.bind(a, aValue, false);

            assertEquals(aValue, _frame.get(a));
            assertEquals(oldTrailSize + 1, _machine._varTrailStack.size());
        }

        public void testBindTemporary() {
            int oldTrailSize = _machine._varTrailStack.size();

            Variable a = new Variable(0, "A");
            Term aValue = new IntConstant(10);
            _frame.bindTemporary(a, aValue);

            assertEquals(aValue, _frame.get(a));
            assertEquals(oldTrailSize + 1, _machine._varTrailStack.size());
        }

        public void testDuplicateBindTemporary() {
            Variable a = new Variable(0, "A");
            Term aValue = new IntConstant(10);
            _frame.bindTemporary(a, aValue);

            try{
                _frame.bindTemporary(a, aValue);
                fail("AssertionError expected");
            }catch(AssertionError ex){
            }
        }

        public void testDuplicateBind() {
            Variable a = new Variable(0, "A");
            Term aValue = new IntConstant(10);
            _frame.bind(a, aValue,true);

            try{
                _frame.bind(a, aValue,true);
                fail("AssertionError expected");
            }catch(AssertionError ex){
            }
        }
    }
}

Ik hoor hier ook mensen roepen over "geautomatiseerd" unit testen praten: hoe werkt dat? Waarmee doe je dat?

Ik laat gewoon mijn testsource directories afscannen naar XXXTestSuite.java bestanden en die uitvoeren. Ik hoef dus mijn testsuites nergens meer aan te melden, maar kwak ze gewoon in mijn testsource dir.

[ Voor 8% gewijzigd door Alarmnummer op 22-08-2004 22:40 ]

[Verwijderd]

Ik heb met JUnit voor het eerst automatisch getest, maar ik vond het niet echt helpen om fouten te vinden, en ik vond het ook irritant werken.

Ik heb sinds gisteren een andere tool gebruikt in een andere taal, en die heeft exact weergegeven waarop mijn algoritme niet werkte(nu was het zo dat ik in een aantal gevallen wist dat er nooit met die input op zou worden aangeroepen door mijzelf, maar er was ook een geval waar ik zelf niet aan had gedacht).

Ik vind Unit testing (mits random) behoorlijk goed. Maar verificatie is natuurlijk wat je eigenlijk wilt. Ik denk dat het alleen nog wel een tijdje duurt, voordat het in elke applicatie zit...

[Alarmnummer]

Verwijderd schreef op 22 augustus 2004 @ 23:20:
Ik heb met JUnit voor het eerst automatisch getest, maar ik vond het niet echt helpen om fouten te vinden, en ik vond het ook irritant werken.

Unit testen leer je niet uit boeken en heb je niet in 1 avond onder de knie. Reken eerder maar op een aantal maanden voordat je alles beetje goed onder de knie hebt en alles naar je hand kan zetten (vooral als je ook met allerlei extensies te maken krijgt)

En in het begin heb je ook het gevoel dat je niet opschiet. Al dat gezanik. Ik heb die functie toch net geschreven? Ik weet toch dat ie het goed doet? Yep.. maar na verloop van tijd, als je gaat refactoren dan begin je die zekerheid te verliezen. En als je dan moet gaan zoeken naar een bug, tja.. waar moet je beginnen? En dan begint die extra inspanning zijn waarde te tonen. Als een systeem voor een serieuze toepassing ingezet moet worden (dus geen kladjes/thuisknutselwerken of schoolopdrachten), dan zit je veel meer in de onderhoud dan in de ontwikkeling. En dan ben je heeeel blij met testen.

Ik vind Unit testing (mits random) behoorlijk goed. Maar verificatie is natuurlijk wat je eigenlijk wilt. Ik denk dat het alleen nog wel een tijdje duurt, voordat het in elke applicatie zit...

Je moet niet random gaan werken. Je moet de kantelpunten van functies pakken (en in principe ben je dan aan het whitebox testen) en daar tests van maken. Controleren of je systeem na calls wel in een goeie toestand achterblijft. Kijken of alle invarianten nog gelden (en design by contract is een betere oplossing.. maar we zitten nu met de huidige beperkingen.. en daar moeten we het beste van zien te maken... ) De normale developers werken met redelijke mainstreamtalen.. dus tja.. dan moet je het beste ervan maken.

[ Voor 21% gewijzigd door Alarmnummer op 22-08-2004 23:57 ]

[Verwijderd]

Het leuke aan unit testing is dat je gedwongen wordt om functies tot in het extreme op te splitsen, want anders is het gewoon te moeilijk om nuttige unit testen te maken

Alarmnummer schreef op 22 augustus 2004 @ 17:45:Mijn huidige prologcompiler+abstract machine heeft voor iedere regel code ook bijna een regel unit test code.

Hoe test je regel per regel? Je kan toch in principe maar hele functies testen? Ik vind het altijd zo moeilijk om hele algoritmes te testen (bijv. een heapsort van 200 regels, waarvan het niet zinvol is om verder op te splitsen), omdat je alleen de input & overeenkomstige output (+ natuurliljk het effect van de functie zelf) kan nagaan?

[ Voor 68% gewijzigd door Verwijderd op 23-08-2004 00:13 ]

[Alarmnummer]

Hoe test je regel per regel? Je kan toch in principe maar hele functies testen? Ik vind het altijd zo moeilijk om hele algoritmes te testen (bijv. een heapsort van 200 regels, waarvan het niet zinvol is om verder op te splitsen), omdat je alleen de input & overeenkomstige output (+ natuurliljk het effect van de functie zelf) kan nagaan?

Ik bedoel dat ik voor iedere 100 regels code ook 100 regels testcode heb Als ik mijn analyse tool ff over de test-src en de src dir gooi staan er ongeveer evenveel regels code.

[Verwijderd]

Alarmnummer schreef op 23 augustus 2004 @ 00:15:
[...]

Ik bedoel dat ik voor iedere 100 regels code ook 100 regels testcode heb Als ik mijn analyse tool ff over de test-src en de src dir gooi staan er ongeveer evenveel regels code.

Oh

[Verwijderd]

Alarmnummer schreef op 22 augustus 2004 @ 23:45:
Unit testen leer je niet uit boeken en heb je niet in 1 avond onder de knie.

Ik denk dat je het wel degelijk uit boeken kan leren, mits de boeken goed zijn, maar er zijn maar weinig mensen die zo leren. Dat je het niet in 1 avond onder knie hebt, is ook mensafhankelijk, maar ik denk dat er inderdaad weinig mensen zijn die dat kunnen.

Je moet niet random gaan werken.

Als je random werkt met grensgevallen gaat het heel goed.

Ik snap ook wel dat het weinig zin heeft om een programma die strings print (ik noem maar iets) te testen op "a" en "b", omdat ze teveel op elkaar lijken. Maar ik denk dat je best heuristieken kan maken, om er voor te zorgen dat je die testen niet met de hand hoeft te schrijven (daar heb ik dus echt een hekel aan (al dat low-level geneuzel)).

Ik heb daarom ook een hekel aan JUnit. Het is zo low-level als maar zijn kan.
Ik wilde de tools niet noemen(omdat het dan weer zo'n taaldiscussie wordt), maar ik zou zeggen: vergelijk QuickTest eens met HUnit.

Ik keek naar de voorbeelden bij beiden, en ik was er *heel* snel uit welke ik in ieder geval niet moest hebben.

[Alarmnummer]

Verwijderd schreef op 23 augustus 2004 @ 01:00:
[...
Ik denk dat je het wel degelijk uit boeken kan leren, mits de boeken goed zijn, maar er zijn maar weinig mensen die zo leren.

Menselijke developers leren het in ieder geval niet uit boeken. En ik heb intussen meer dan genoeg testboeken gelezen. Als je wilt kan ik hier wel ff een lijstje posten. Verder moet je een bepaald balans zien te vinden tussen wat te testen en wat niet. Het is ook niet de bedoeling dat je met unit testen alle bugs in je fouten gaat opsporen, maar je gaat er zoveel opsporen dat het je nog tijd gaat besparen.

Wat ik vaak doe is dat ik de testsuites na verloop van tijd steeds meer ga uitbreiden. Dus is een systeem klaar maar is het wel een enorm belangrijk onderdeel in het geheel? Dan zal ik in geval van twijfel nieuwe tests gaan toevoegen.

JUnit is niet de oplossing.. maar het is wel een stap in de goeie richting.

Ik snap ook wel dat het weinig zin heeft om een programma die strings print (ik noem maar iets) te testen op "a" en "b", omdat ze teveel op elkaar lijken. Maar ik denk dat je best heuristieken kan maken, om er voor te zorgen dat je die testen niet met de hand hoeft te schrijven (daar heb ik dus echt een hekel aan (al dat low-level geneuzel)).

Ik zou zeggen: doe een echte ervaring op ipv schoolbank ervaring en kom dan eens terug.

We (echte developers) leven in een echte wereld waar we niet de meest exotische tools/talen kunnen gebruiken maar moeten werken binnen de beperkingen die er zijn. Dan kom je uit bij talen zoals Java en testframeworks zoals JUnit. Als jij iets beters kan maken dan zou ik zeggen: doe dat. Ik zal dan met extreem veel plezier dat ook gaan gebruiken omdat ik ook niet alleen een pure liefdesverhouding met unit testen heb. Maar tot op heden, is het de beste oplossing die ik heb gevonden.

[ Voor 44% gewijzigd door Alarmnummer op 23-08-2004 08:03 ]

[Alarmnummer]

Ik heb net Clover geinstalleerd. Dit is een programma waarmee gekeken wordt welke code allemaal tijdens het testen is uitgevoerd. Je kan dus goed zien welke stukken code zijn getest en welke niet.



*A is verliefd*

[edit]
Dit is de plugin voor IDEA. Clover kan ook als een losstaande applicatie functioneren.

[ Voor 14% gewijzigd door Alarmnummer op 27-08-2004 19:58 ]

[alienfruit]

Ik ook JBuilder ondersteuning

[misfire]

Ik zou zeker durven stellen dat als je geen gestructureerde testscenario's hebt je nooit een veilige real-world applicatie kunt bouwen. Met ad-hoc testen kun je nooit een uitspraak doen over de dekking van je testen, en dus ook niks zeggen over de veiligheid. Zonder testen kun je in feite niets zeggen over de werking van je applicatie.

Unit testen is één van de vele vormen van testen die de laatste tijd vrij populair is. Om een aantal potentiële exploits (zoals buffer/pointer trucs, sql injection en verkeerd/niet gecontroleerde rechten) te kunnen voorkomen zou je er unit tests voor kunnen maken. Merk echter op dat voor zaken als buffer-over/underruns er al in de (compiler) infrastructuur beveiligingen aanwezig zijn tegenwoordig.

Unit testen draaien in principe zeer dicht bij de unit die ze testen, en interacteren slechts met een beperkt onderdeel (unit) van de applicatie. Afhankelijk van je architectuur filosofie (bijvoorbeeld checking-at-the-gate) zal je met unit testen niet alle aspecten geïsoleerd kunnen testen. Unit testen kunnen ook geen processen buiten het systeem testen, bijvoorbeeld of de administrator wel netjes de rechten uitdeelt of de firewall goed instelt.

Je zult uiteindelijk dus toch met een combinatie van geautomatiseerde (unit) testen, controle lijsten en testprocedures aan de slag moeten.