Hi Andres We can convert them to PyUnit unit tests. From [0]:
In some cases, the existing tests may have been written using the doctest module. If so, doctest provides a DocTestSuite class that can automatically build unittest.TestSuite instances from the existing doctest-based tests. I spent two hours to write my first unit tests in python, yay ;) I used the examples referenced on this [1] page. I wrote a test class for the levenshtein class. See attachements. Some of the tests failed. That's why I changed the levenshtein class again and now all tests succeed :). Feedback appreciated. cheers floyd [0] http://docs.python.org/library/unittest.html [1] http://spi.cern.ch/testing/HowTo-TestFramework-PyUnit.html ----- http://www.floyd.ch ________________________________ Von: Andres Riancho <andres.rian...@gmail.com> An: Floyd Fuh <floyd_...@yahoo.de> CC: "w3af-develop@lists.sourceforge.net" <W3af-develop@lists.sourceforge.net> Gesendet: Samstag, den 2. Oktober 2010, 13:49:50 Uhr Betreff: Re: [W3af-develop] Unit test framework for w3af One more question: some minor pieces of w3af code have doc-tests, do you guys know if there is a way to integrate pyunit with doctests? Regards, -- Andres Riancho El oct 2, 2010 8:10 a.m., "Floyd Fuh" <floyd_...@yahoo.de> escribió: > >Andres, > > >>> For unit testing, PyUnit (http://pyunit.sourceforge.net/) is the obvious >>> choice for Python. >>...I think we all agree on PyUnit :) . With PyUnit we may be already able >to get 50% to 70% code (test) coverage. > > >>> However, as soon as you start talking http server (or any server), by >>> definition you aren't d...I think we should distinguish between unit tests >>> (the >>>code does >what we want) and performance tests. For performance tests (for the >entire framework) I would still use a server like before (Moth [0] to be >precise). > > >> >>> For integration and functional testing, most of the frameworks rely on >>> driving a browser (e...If we talk about unit tests I think it is not a good >>>idea to use a real server. >The tests would take very long, because the HTTP requests have to be really >sent over the network. Tests should be easy to execute. Everybody who does >a SVN checkout should be able to run 1 command on the command line and >see which tests fail (without the need of a web server). > >I think the best would be to mock out the methods of the >xUrllib. Example for the xss plugin (see Gene's link to mockito [1]): > >responseHeaders = {"Content-Type":"text/html"} >xUrllibMock = mock(xUrllib) >payload = '</A/style="xss:exp/**/ression(alert(\'XSS\'))">' >url = "http://example.com/a.php?abc="+payload >#Now here's the real magic happening: >when(xUrllibMock).GET(url).thenReturn(httpResponse(200, payload, >responseHeaders, url, url)) >#Now use the mock object >basePlugin._urlOpener = xUrllibMock >#Now we would start the scan and check that the XSS was found with asserts or >whatever >... > >Of course this is a LOT of work. We have to rebuild real-world vulnerabilites >in our test cases. > > >>> Both types of testing have value, but the integration testing is what I >>> think you are looking...I think it is a good idea to start with PyUnit and >>> easy >>>methods (that don't >need mock objects). > >Just what came to my mind. > >cheers >floyd > >[0] http://www.bonsai-sec.com/en/research/moth.php >[1] http://code.google.com/p/mockito-python/ > > >>> >>> On Fri, Oct 1, 2010 at 11:46 AM, Andres Riancho <andres.rian...@gmail.com> >>> wrote: >>>> >>>> ...
levenshteintest.py
Description: Binary data
levenshtein.py
Description: Binary data
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
