From: <kl...@hy...> - 2004-03-18 15:04:17
|
Folks, we have 1.43 released. It's got many many internal changes. As I've wrote a while ago, I feel that the need for some automated regression testing is becoming ... well urgent. See release notes at http://yaws.hyber.org Enjoy, and comment. I plan to make this release relatively shortlived. Next thing on my agenda is automated tests, and I expect to ... well find some bugs there . Also, since I've done extensive surgery to the core, I might have broken some features in this release. Hopefully not though. But, it's hard to say. Regardless of broken features or not, this release is, well, more beautiful than before. I've cleaned alot in the code. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |
From: Carsten S. <ca...@ba...> - 2004-03-18 16:49:45
|
Hi klacke! On Thu, Mar 18, 2004 at 04:04:09PM +0100, kl...@hy... wrote: > Folks, we have 1.43 released. It's got many many internal > changes. As I've wrote a while ago, I feel that the need for > some automated regression testing is becoming ... well urgent. I think an automated way to do performance tests would be great also. Some parts of the code I also found could be more modular, but at the same time we do not want to breaks yaws' property of being the fasted fully functional web server known to mankind :-) > Enjoy, and comment. I plan to make this release relatively > shortlived. Then a cvs commit and a request for tests might have been enough? > Also, since I've done extensive surgery to the core, I might have > broken some features in this release. Hopefully not though. > But, it's hard to say. Regardless of broken features or not, this > release is, well, more beautiful than before. I've cleaned alot > in the code. I am looking forward to read some code and do some testing in the next few days. Just coming to my mind: It seems that the make file never noticed a version change and did not regenerate yaws_vsn.erl or what it's called when using cvs. Greetings, Carsten |
From: Nicolas N. <nicolas.niclausse@IDEALX.com> - 2004-03-19 11:20:53
|
>>>>> "Carsten" =3D=3D Carsten Schultz <ca...@ba...th.fu-berlin.d= e> =E9crivait: Carsten> Hi klacke! Carsten> On Thu, Mar 18, 2004 at 04:04:09PM +0100, kl...@hy... wrot= e: >> Folks, we have 1.43 released. It's got many many internal >> changes. As I've wrote a while ago, I feel that the need for some >> automated regression testing is becoming ... well urgent. Carsten> I think an automated way to do performance tests would be Carsten> great also.=20 Maybe we could use IDX-Tsunami to do that ? It's a load testing tool written in Erlang : http://tsunami.idealx.org/index.en.html --=20 Nicolas NICLAUSSE IDEALX S.A.S. T=E9l:01 44 42 00 00 http://IDEALX.com/ |
From: Mickael R. <mic...@er...> - 2004-03-19 17:06:24
|
On Fri, 19 Mar 2004 12:18:54 +0100, Nicolas Niclausse =20 <nicolas.niclausse@IDEALX.com> wrote: >>>>>> "Carsten" =3D=3D Carsten Schultz <ca...@ba...th.fu-berlin.= de> =20 >>>>>> =E9crivait: > > Carsten> Hi klacke! > Carsten> On Thu, Mar 18, 2004 at 04:04:09PM +0100, kl...@hy... =20 > wrote: > >> Folks, we have 1.43 released. It's got many many internal > >> changes. As I've wrote a while ago, I feel that the need for some > >> automated regression testing is becoming ... well urgent. > > Carsten> I think an automated way to do performance tests would be > Carsten> great also. > > Maybe we could use IDX-Tsunami to do that ? I use it and it is a very good tool. However, what Klacke wants is =20 something to do non-regression and functional tests. IDX-Tsunami does not= =20 allow as is to test the content of an HTTP request (It only traces the =20 return code). If your are interest, maybe we could extend to support some form of =20 regression testing. Please, tell us if this tool could fit your need with some modifications. Cheers, --=20 Micka=EBl R=E9mond http://www.erlang-projects.org/ |
From: <kl...@hy...> - 2004-03-19 23:41:48
|
On Fri, Mar 19, 2004 at 06:01:41PM +0100, Mickael Remond wrote: > If your are interest, maybe we could extend to support some form of > regression testing. > > Please, tell us if this tool could fit your need with some modifications. > I'll have a good look at it, however here are my current thoughts on _regression_ tests of a webserver such as yaws. - It can't be done automatically. Period. - Before even thinking of regression testing yaws we need a test suite, that is a set of pages (large set) that utilize the features of yaws. This is a good thing which I intend to create. Boring, but good (TM) - Once we have that, an idiots regression testing is the equivalent of clicking (with mozilla/ie/netscape/opera/konqueror/curl) onself through all those cases. Ok, would be if everything renders nicely in the browser, Hahahahjaha. - Recording/replay, packet traces, tun/tap solutions wount do it. worthless. Say we add/change a header. Replays break. Also recoring at packet level makes backtrace hard. Which testcase failed and why. Same thing with recoring at TCP level in the application. Arghhhh, darkness. I see myself clicking through endless series of testcases with IE 18.79 Thunderbolt (or whatever it will be called) in 2 years from now !!!!! (And don't you fucking laugh there) /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |
From: Mickael R. <mic...@er...> - 2004-03-22 14:08:21
|
On Sat, 20 Mar 2004 00:41:37 +0100, <kl...@hy...> wrote: > - Recording/replay, packet traces, tun/tap solutions wount do it. > worthless. Say we add/change a header. Replays break. Also > recoring at packet level makes backtrace hard. Which testcase > failed and why. Same thing with recoring at TCP level in the > application. IDX-Tsunami is a very good tool if you want to record and replay scenarii= . =20 It comes with a proxy that you can use to record a user scenario. You can= =20 then insert the result into a IDX-Tsunami scenario file to replay it. The= =20 benefit compared to packet level recording is that IDX-Tsunami take care = =20 of managing cookies for example: It does not record cookies in the =20 scenario and manage cookie when running the scenario (Storing it when the= =20 server send it and reusing it during the scenario) I think that this simple feature only could be very useful to test Yaws. When producing the stats, it also generate answer graphes of HTTP code =20 responses. It's easy to track code 500 error :-). And most of all, it can generate performance graphes, simulating many =20 simultaneous users, with a realistic stochastic load. I think it is a good tool that should fit, at least partially, your need. --=20 Micka=EBl R=E9mond http://www.erlang-projects.org/ |