This reminds me of one idea that I had for the functional tests. Since
some tests would require some sort of client to connect, I was thinking
about doing this:
Fixing up the python client libs that I had a start on. In a functional
test map that wants a 'player', make a script that uses crossfi
Mark Wedel a écrit :
> Random question - is there any framework in place for external functional
> tests?
>
>
>
no
> I ask because to reproduce and confirm I fixed the setup buffer overflow
> bug,
>I do have an external perl script which would be nice to toss somewhere.
>
>___
Random question - is there any framework in place for external functional
tests?
I ask because to reproduce and confirm I fixed the setup buffer overflow bug,
I do have an external perl script which would be nice to toss somewhere.
___
crossfire
In fact buffer overflow will probably be reduced by unit testing because
of unexpeted behaviour of some functions when called with long parameters.
Alex Schultz a écrit :
>That would be more functional testing than unit testing, however both
>are planned in the framework. security functional tes
That would be more functional testing than unit testing, however both
are planned in the framework. security functional testing may be a good
idea to include some of. Perhaps some thing like attempted buffer
overflows over the protocol, or verifying that the password code isn't
making any silly
Yay. There should be added some security unit tests
aswell.
--- tchize <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> While am still preparing check framework for
> crossfire, i found a bug
> in common/shstr.c where query_refcount was returning
> wrong value.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
While am still preparing check framework for crossfire, i found a bug
in common/shstr.c where query_refcount was returning wrong value.
Fixed and commited. I hope unit testing will discover more of those
still undetected bugs :)
Tchize
-BEGIN PGP
7 matches
Mail list logo
