Pharo/Seaside UI testing
Locked
12
12
 
|
I have to say, I am loving the Pharo/Seaside development environment.
Manually testing TFLogin (a basic login and user account management package for Seaside) using Firefox was taking longer and longer as added features multiplied the number of cases to be tested. I had unit tests for the underlying pieces; testing the callbacks on the rendered pages was where most of my time was being spent. Yesterday I loaded WebClient and Soup from Squeaksource and together they made it possible for me to script tests of the TFLogin Web UI without needing a browser. This even includes verifying confirmation email callbacks. I've constructed web apps in other environments (e.g. LAMP, ASP) and never had this level of automated testing. Its surely not impossible in other development environments, but somehow it never happened. I've been thinking about why in the Pharo/Seaside environment this seemed so natural and I've come up with these reasons: 1. It required no extra infrastructure or products to set up the test environment. Seaside's server, the WebClient clients, Soup, and the TFLogin test app are all present in the Pharo image. 2. No shell scripts or Perl or Python code was necessary. 3. The tests cases are integrated into the development environment, and are not in another tool or language. Regards, TF _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
Hi Tony,
I'm sure some of us would appreciate it if you wrote a short post or mini-howto explaining how have you dealt with Soup and WebClient to write your test cases :)
Best, Bernat Romagosa.
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I'll be happy to do that. I'll attack it tomorrow. (Being new to
Pharo/Seaside myself, I just assumed that everyone was already using these tools for this purpose.) TF On Mon, Jan 10, 2011 at 5:10 PM, AxiNat <[hidden email]> wrote: > Hi Tony, > I'm sure some of us would appreciate it if you wrote a short post or > mini-howto explaining how have you dealt with Soup and WebClient to write > your test cases :) > > Best, > Bernat Romagosa. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
On Tue, Jan 11, 2011 at 3:34 AM, Tony Fleig <[hidden email]> wrote: I'll be happy to do that. I'll attack it tomorrow Thank you !! Laurent . (Being new to _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by tfleig
Why didn't you try SeasideTesting and/or WebTester?
On 11 Jan 2011, at 01:51, Tony Fleig wrote: > I have to say, I am loving the Pharo/Seaside development environment. > > Manually testing TFLogin (a basic login and user account management > package for Seaside) using Firefox was taking longer and longer as > added features multiplied the number of cases to be tested. I had unit > tests for the underlying pieces; testing the callbacks on the rendered > pages was where most of my time was being spent. > > Yesterday I loaded WebClient and Soup from Squeaksource and together > they made it possible for me to script tests of the TFLogin Web UI > without needing a browser. This even includes verifying confirmation > email callbacks. > > I've constructed web apps in other environments (e.g. LAMP, ASP) and > never had this level of automated testing. Its surely not impossible > in other development environments, but somehow it never happened. I've > been thinking about why in the Pharo/Seaside environment this seemed > so natural and I've come up with these reasons: > > 1. It required no extra infrastructure or products to set up the test > environment. Seaside's server, the WebClient clients, Soup, and the > TFLogin test app are all present in the Pharo image. > > 2. No shell scripts or Perl or Python code was necessary. > > 3. The tests cases are integrated into the development environment, > and are not in another tool or language. > > Regards, > TF > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
In reply to this post by tfleig
Hi Tony,
I'd be very interested to compare you testing approach with Selenium-RC method see:
Nick On 11 January 2011 00:51, Tony Fleig <[hidden email]> wrote: I have to say, I am loving the Pharo/Seaside development environment. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by laurent laffont
I have written up my Seaside automated testing experience here:
http://www.tonyfleig.com/smallthoughts/blog/seasideautomatedtesting. Regards, TF On Mon, Jan 10, 2011 at 10:27 PM, laurent laffont <[hidden email]> wrote: > > On Tue, Jan 11, 2011 at 3:34 AM, Tony Fleig <[hidden email]> wrote: >> >> I'll be happy to do that. I'll attack it tomorrow > > Thank you !! > Laurent > > >> >> . (Being new to >> Pharo/Seaside myself, I just assumed that everyone was already using >> these tools for this purpose.) >> >> TF >> >> On Mon, Jan 10, 2011 at 5:10 PM, AxiNat <[hidden email]> >> wrote: >> > Hi Tony, >> > I'm sure some of us would appreciate it if you wrote a short post or >> > mini-howto explaining how have you dealt with Soup and WebClient to >> > write >> > your test cases :) >> > >> > Best, >> > Bernat Romagosa. >> > _______________________________________________ >> > seaside mailing list >> > [hidden email] >> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > >> > >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Nick
I was unaware of Selenium-RC, but after watching the video, the big
difference I see is that the WebClient/Soup approach doesn't require any external tools like a Java webserver and doesn't use a browser. I'm not sure that is really a significant difference though, and using the Selenium-RC approach it might be quicker to develop tests. Selenium-RC should make any browser incompatibilities apparent and that is a useful feature. The WebClient/Soup approach might be better suited to automated testing as part of a build process, since it can be executed on a headless server system. Regards, TF On Tue, Jan 11, 2011 at 12:48 AM, Nick Ager <[hidden email]> wrote: > Hi Tony, > I'd be very interested to compare you testing approach with Selenium-RC > method see: > http://www.pharocasts.com/2010/08/web-application-testing-through.html > Nick > On 11 January 2011 00:51, Tony Fleig <[hidden email]> wrote: >> >> I have to say, I am loving the Pharo/Seaside development environment. >> >> Manually testing TFLogin (a basic login and user account management >> package for Seaside) using Firefox was taking longer and longer as >> added features multiplied the number of cases to be tested. I had unit >> tests for the underlying pieces; testing the callbacks on the rendered >> pages was where most of my time was being spent. >> >> Yesterday I loaded WebClient and Soup from Squeaksource and together >> they made it possible for me to script tests of the TFLogin Web UI >> without needing a browser. This even includes verifying confirmation >> email callbacks. >> >> I've constructed web apps in other environments (e.g. LAMP, ASP) and >> never had this level of automated testing. Its surely not impossible >> in other development environments, but somehow it never happened. I've >> been thinking about why in the Pharo/Seaside environment this seemed >> so natural and I've come up with these reasons: >> >> 1. It required no extra infrastructure or products to set up the test >> environment. Seaside's server, the WebClient clients, Soup, and the >> TFLogin test app are all present in the Pharo image. >> >> 2. No shell scripts or Perl or Python code was necessary. >> >> 3. The tests cases are integrated into the development environment, >> and are not in another tool or language. >> >> Regards, >> TF >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Johan Brichau-2
I didn't know about SeasideTesting and I wanted a non-browser-based
test environment which WebTester didn't seem to be. I don't know how I missed finding SeasideTesting. I will load it and give it a try. Thanks for the pointer. Regards, TF On Mon, Jan 10, 2011 at 10:58 PM, Johan Brichau <[hidden email]> wrote: > Why didn't you try SeasideTesting and/or WebTester? > > On 11 Jan 2011, at 01:51, Tony Fleig wrote: > >> I have to say, I am loving the Pharo/Seaside development environment. >> >> Manually testing TFLogin (a basic login and user account management >> package for Seaside) using Firefox was taking longer and longer as >> added features multiplied the number of cases to be tested. I had unit >> tests for the underlying pieces; testing the callbacks on the rendered >> pages was where most of my time was being spent. >> >> Yesterday I loaded WebClient and Soup from Squeaksource and together >> they made it possible for me to script tests of the TFLogin Web UI >> without needing a browser. This even includes verifying confirmation >> email callbacks. >> >> I've constructed web apps in other environments (e.g. LAMP, ASP) and >> never had this level of automated testing. Its surely not impossible >> in other development environments, but somehow it never happened. I've >> been thinking about why in the Pharo/Seaside environment this seemed >> so natural and I've come up with these reasons: >> >> 1. It required no extra infrastructure or products to set up the test >> environment. Seaside's server, the WebClient clients, Soup, and the >> TFLogin test app are all present in the Pharo image. >> >> 2. No shell scripts or Perl or Python code was necessary. >> >> 3. The tests cases are integrated into the development environment, >> and are not in another tool or language. >> >> Regards, >> TF >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Pharo/Seaside UI testing
|
|
In reply to this post by tfleig
Tony , sorry to inform you that I get
"The requested object /pier/blog/seasideautomatedtesting. was not found on this server." when I try your link _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I just tried it and it seemd to work:
There's an updated version usinf Zinc in place of WebClient here: Let me know if it still doesn't work for you. TF
On Wed, Jan 19, 2011 at 7:49 PM, Fritz Schenk <[hidden email]> wrote: Tony , sorry to inform you that I get _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Pharo/Seaside UI testing
|
|
Hey Tony,
On 20 Jan 2011, at 19:18, Tony Fleig wrote: > I just tried it and it seemd to work: > > http://www.tonyfleig.com/smallthoughts/blog/seasideautomatedtesting > > There's an updated version usinf Zinc in place of WebClient here: > > http://www.tonyfleig.com/smallthoughts/blog/seasideautomatedtesting2 > > Let me know if it still doesn't work for you. This is great! Since our last discussion, I was interested to see how the redirects went and I saw that sadly you still had to them manually. So I decided to load all your code and to try to find out what went wrong. (BTW, I was already planning to check out TFLogin, so this was a good first step.) I found the problem and commited a new version of Zn fixing the problem. You could simplify the use of Zn in your code as follows: TLTest>>#setup "...." client := (ZnHttpClient new). client settings followRedirect: true. "actually not needed since this is the default" client settings timeout: 5. TLTest>>#clickOn:in:with: "..." response := (client post: url data: args). "response isRedirect ifTrue: [ url := self baseUrl, (response location). response := client get: url ]." ^ response contents (I added some newer API in the commented out section). This could further be simplified to: ^ (client post: url data: args) contents All TF-Login test are/remain green with these changes. Sven PS: I also applied a small fix to actually honor the timeout ;-) BTW: There is also a Zinc-Seaside adaptor, so you could use the Zn server part as well. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Thanks Sven!
I have updated my test code and uploaded the new version to Squeaksource and updated the blog entry to reflect the changes as well. I'll look at using the Zinc Seaside adaptor was well. (It'd be nice to have the tests run regardless of whether there was already a Seaside server up and running.)
TF
On Thu, Jan 20, 2011 at 12:33 PM, Sven Van Caekenberghe <[hidden email]> wrote: Hey Tony, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Pharo/Seaside UI testing
|
|
On 20 Jan 2011, at 22:01, Tony Fleig wrote: > Thanks Sven! > > I have updated my test code and uploaded the new version to Squeaksource and updated the blog entry to reflect the changes as well. Great! > I'll look at using the Zinc Seaside adaptor was well. > (It'd be nice to have the tests run regardless of whether there was already a Seaside server up and running.) Here you go (all instance methods on TLTest): I removed the port inst var and #port and #port:. (existingPort and wasRunning could also be removed) I added a server instance variable and #server and #server:. #seasideAdaptorClass ^ ZnZincSeasideAdaptor #baseUrl ^ '<a href="http://localhost:'">http://localhost:', self server port asString #setUp self server: (self seasideAdaptorClass port: 12345) start. self assert: (self server isRunning ) description: 'This test needs a Seaside server.'. "..." #tearDown "..." self server unregister The only 'disadvantage' is that the server is started/stopped for each test (method) but that is part of the idea of SUnit (start each test with fresh objects). I believe there exists something like a shared testing resource but I have never used it. Regards, Sven PS: some other constructive remarks: - it is better to move the unit tests and related code (like the test app) to a testing package (your test suite is big enough to stand on its own, it gives users the option to skip the tests in deploy images, unclutters the packages, besides, the automatic app install in not always wanted) - the documentation workspace is very impressive, however opening it automatically is a deal breaker on headless images (where one can load newer versions using MC and a web interface) _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Thanks yet again Sven!
I have made all the changes you suggested. However, one test fails in my environment after switching to the Zinc Seaside adaptor: the TLTest>>#testForgotUsername test. This test is not very different from all the other tests that pass and of course it passes using the WAKom server. I have no idea why only this test is failing. Its failing on to a ConnectionTimedOut error in Socket>>#waitForData processing a ZnClient>>#post:data: request. This is reproducible in OSX SnowLeopard, but it does not occur at all in Ubuntu Linux 9.10 or Windows 7. I doubled the timeout period, but all that did was cause me to wait longer for the error. If you want to investigate this, you can use the latest TF-Login (and TF-Login-Tests) package from Squeaksource. Change the method TLTest>>#useZincServer to return true to use the Zinc server. If you don't have access to a Mac, I suppose I can investigate further here. Regards, TF On Fri, Jan 21, 2011 at 3:02 AM, Sven Van Caekenberghe <[hidden email]> wrote: > > On 20 Jan 2011, at 22:01, Tony Fleig wrote: > >> Thanks Sven! >> >> I have updated my test code and uploaded the new version to Squeaksource and updated the blog entry to reflect the changes as well. > > Great! > >> I'll look at using the Zinc Seaside adaptor was well. >> (It'd be nice to have the tests run regardless of whether there was already a Seaside server up and running.) > > Here you go (all instance methods on TLTest): > > I removed the port inst var and #port and #port:. (existingPort and wasRunning could also be removed) > > I added a server instance variable and #server and #server:. > > #seasideAdaptorClass > ^ ZnZincSeasideAdaptor > > #baseUrl > ^ '<a href="http://localhost:'">http://localhost:', self server port asString > > #setUp > self server: (self seasideAdaptorClass port: 12345) start. > self assert: (self server isRunning ) description: 'This test needs a Seaside server.'. > "..." > > #tearDown > "..." > self server unregister > > The only 'disadvantage' is that the server is started/stopped for each test (method) but that is part of the idea of SUnit (start each test with fresh objects). I believe there exists something like a shared testing resource but I have never used it. > > Regards, > > Sven > > PS: some other constructive remarks: > > - it is better to move the unit tests and related code (like the test app) to a testing package (your test suite is big enough to stand on its own, it gives users the option to skip the tests in deploy images, unclutters the packages, besides, the automatic app install in not always wanted) > > - the documentation workspace is very impressive, however opening it automatically is a deal breaker on headless images (where one can load newer versions using MC and a web interface) > > > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Pharo/Seaside UI testing
|
|
On 22 Jan 2011, at 19:41, Tony Fleig wrote: > Thanks yet again Sven! You're welcome. > I have made all the changes you suggested. > > However, one test fails in my environment after switching to the Zinc > Seaside adaptor: the TLTest>>#testForgotUsername test. This test is > not very different from all the other tests that pass and of course it > passes using the WAKom server. I have no idea why only this test is > failing. > > Its failing on to a ConnectionTimedOut error in Socket>>#waitForData > processing a ZnClient>>#post:data: request. This is reproducible in > OSX SnowLeopard, but it does not occur at all in Ubuntu Linux 9.10 or > Windows 7. I doubled the timeout period, but all that did was cause me > to wait longer for the error. > > If you want to investigate this, you can use the latest TF-Login (and > TF-Login-Tests) package from Squeaksource. Change the method > TLTest>>#useZincServer to return true to use the Zinc server. > > If you don't have access to a Mac, I suppose I can investigate further here. Well, I loaded the new MC packages and all tests are green both using Kom and Zn adaptors. And yes, my primary platform is Mac OS X 10.6.6. Typically, a ConnectionTimedOut from Zn client means that the server just did not respond at all. Sven PS: the new packages look great. the workspace still popped up though, maybe on older initialize or something. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hmm. Mysterious. The failure is very consistent in my environment, but only on that test. I'll try to track it down here... Are you working on a weekend? In Belgium? Regards, TF On Sat, Jan 22, 2011 at 1:51 PM, Sven Van Caekenberghe <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Pharo/Seaside UI testing
|
|
On 23 Jan 2011, at 01:08, Tony Fleig wrote: > Hmm. Mysterious. The failure is very consistent in my environment, but only on that test. I'll try to track it down here... > > I put in a "headless-detector" (TLLoginComponentBase class>>#smalltalkImageHasDisplay) so the docs workspace should not pop up in headless environments. Sorry, sorry, my fault: I just didn't look and assumed you forgot, since the workspace came up when I loaded the new version, but that was in a developer image. You built this nice test, clever! > Are you working on a weekend? In Belgium? Yes, it is a weekend. Since I have my own company I have no real hours. And programming, especially the stuff that I love, like Smalltalk, is as much a hobby as it is work. The idea is to use as much Smalltalk in paying work as possible. Sven _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Pharo/Seaside UI testing
|
|
In reply to this post by Intrader Intrader
indeed, thanks
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Pharo/Seaside UI testing
|
|
In reply to this post by Intrader Intrader
Your new links work.
The blog article is very clear and helpful. It occurred to me that a lot of the Soup stuff has characteristics of jQuery for the clientside. Is it possible to have Zinc create a server-side version of the Dom which could be traversed via a jQuery for the server-side. Some years ago I provided a server-side validation suite that used the same code used in the client. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |