You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Richard Hirsch <hi...@gmail.com> on 2009/11/10 09:02:47 UTC
Test Cases
Based on the fact that I made a build yesterday that led to a
non-functional app on stax, I started to think about tests in general
and the fact that we will soon need more tests to have some degree of
quality assurance.
I've started a wiki page
(http://cwiki.apache.org/confluence/display/ESME/Tests) with test
cases.
Ideally, we should have some sort of a test driver that tests the UI
as well during the build process. If I remember correctly, cactus has
something like this. I'll take a look and see if I find something that
we can use.
D.
Re: Test Cases
Posted by Markus Kohler <ma...@gmail.com>.
Hi all,
Selenium tests do not have to be based on Javascript anymore.
One can use http://code.google.com/p/webdriver/ for example to drive the
browser directly using it's native API's and get around the limitations of
javascript.
I know for example some popups in IE cannot really be accessed by Javascript
driven tests.
I guess ESME ATM would not use such features, but some portals do ;)
Regards,
Markus
On Tue, Nov 10, 2009 at 9:48 AM, Vassil Dichev <vd...@apache.org> wrote:
> > Selenium looks good.
> >
> > The maven plug-in is here:
> http://mojo.codehaus.org/selenium-maven-plugin/
> >
> >>I believe that Comet based applications are very hard to test properly
> without running a real browser.
> >
> > I agree. At this point, I'm more interested to get tests that deal
> > with basic UI functionality (create message, create action, etc.) to
> > make sure things don't break after code changes. I also don't know if
> > our tabs will mess up the tests. I'll check it out
>
> They shouldn't if the tests are written properly, i.e. using the ids
> of the elements.
>
Re: Test Cases
Posted by Vassil Dichev <vd...@apache.org>.
> Selenium looks good.
>
> The maven plug-in is here: http://mojo.codehaus.org/selenium-maven-plugin/
>
>>I believe that Comet based applications are very hard to test properly without running a real browser.
>
> I agree. At this point, I'm more interested to get tests that deal
> with basic UI functionality (create message, create action, etc.) to
> make sure things don't break after code changes. I also don't know if
> our tabs will mess up the tests. I'll check it out
They shouldn't if the tests are written properly, i.e. using the ids
of the elements.
Re: Test Cases
Posted by Richard Hirsch <hi...@gmail.com>.
Selenium looks good.
The maven plug-in is here: http://mojo.codehaus.org/selenium-maven-plugin/
>I believe that Comet based applications are very hard to test properly without running a real browser.
I agree. At this point, I'm more interested to get tests that deal
with basic UI functionality (create message, create action, etc.) to
make sure things don't break after code changes. I also don't know if
our tabs will mess up the tests. I'll check it out
D.
On Tue, Nov 10, 2009 at 9:23 AM, Markus Kohler <ma...@gmail.com> wrote:
> Hi all,
> I think Selenium (http://seleniumhq.org/) can also be used from within a
> Hudson server.
> It supports a lot of drivers for the different "real" browsers, such as
> Firefox IE, as well as htmlunit, which simulates a browser within a JVM
> (with some limitations).
>
> I started to create a loadtest using Testmaker
> <http://www.pushtotest.com/Downloads/features.html>
> http://www.pushtotest.com/<http://www.pushtotest.com/Downloads/features.html>
> which
> also supports running
> Selenium htmlunit tests as performance test.
>
> I believe that Comet based applications are very hard to test properly
> without running a real browser.
>
>
> Regards,
> Markus
>
> On Tue, Nov 10, 2009 at 9:17 AM, Richard Hirsch <hi...@gmail.com>wrote:
>
>> But the question is how to do perform the UI tests during the build
>> process. It is also possible for each developer to test the UI locally
>> before the commits but this is very inefficient.
>>
>> D
>>
>>
>> On Tue, Nov 10, 2009 at 9:11 AM, Vassil Dichev <vd...@apache.org> wrote:
>> > Tests and documentation are definitely priority No.1 for me for the
>> > next couple of months.
>> >
>> > From my previous experience with Cactus the framework starts the
>> > container and connects to the test runner inside the container, which
>> > then has all the contexts it needs. We are already doing the same
>> > thing by running an embedded Jetty server, so I think we don't need
>> > it.
>> >
>> > Vassil
>> >
>> >
>> > On Tue, Nov 10, 2009 at 10:02 AM, Richard Hirsch <hi...@gmail.com>
>> wrote:
>> >> Based on the fact that I made a build yesterday that led to a
>> >> non-functional app on stax, I started to think about tests in general
>> >> and the fact that we will soon need more tests to have some degree of
>> >> quality assurance.
>> >>
>> >> I've started a wiki page
>> >> (http://cwiki.apache.org/confluence/display/ESME/Tests) with test
>> >> cases.
>> >>
>> >> Ideally, we should have some sort of a test driver that tests the UI
>> >> as well during the build process. If I remember correctly, cactus has
>> >> something like this. I'll take a look and see if I find something that
>> >> we can use.
>> >>
>> >> D.
>> >>
>> >
>>
>
Re: Test Cases
Posted by Markus Kohler <ma...@gmail.com>.
Hi all,
I think Selenium (http://seleniumhq.org/) can also be used from within a
Hudson server.
It supports a lot of drivers for the different "real" browsers, such as
Firefox IE, as well as htmlunit, which simulates a browser within a JVM
(with some limitations).
I started to create a loadtest using Testmaker
<http://www.pushtotest.com/Downloads/features.html>
http://www.pushtotest.com/<http://www.pushtotest.com/Downloads/features.html>
which
also supports running
Selenium htmlunit tests as performance test.
I believe that Comet based applications are very hard to test properly
without running a real browser.
Regards,
Markus
On Tue, Nov 10, 2009 at 9:17 AM, Richard Hirsch <hi...@gmail.com>wrote:
> But the question is how to do perform the UI tests during the build
> process. It is also possible for each developer to test the UI locally
> before the commits but this is very inefficient.
>
> D
>
>
> On Tue, Nov 10, 2009 at 9:11 AM, Vassil Dichev <vd...@apache.org> wrote:
> > Tests and documentation are definitely priority No.1 for me for the
> > next couple of months.
> >
> > From my previous experience with Cactus the framework starts the
> > container and connects to the test runner inside the container, which
> > then has all the contexts it needs. We are already doing the same
> > thing by running an embedded Jetty server, so I think we don't need
> > it.
> >
> > Vassil
> >
> >
> > On Tue, Nov 10, 2009 at 10:02 AM, Richard Hirsch <hi...@gmail.com>
> wrote:
> >> Based on the fact that I made a build yesterday that led to a
> >> non-functional app on stax, I started to think about tests in general
> >> and the fact that we will soon need more tests to have some degree of
> >> quality assurance.
> >>
> >> I've started a wiki page
> >> (http://cwiki.apache.org/confluence/display/ESME/Tests) with test
> >> cases.
> >>
> >> Ideally, we should have some sort of a test driver that tests the UI
> >> as well during the build process. If I remember correctly, cactus has
> >> something like this. I'll take a look and see if I find something that
> >> we can use.
> >>
> >> D.
> >>
> >
>
Re: Test Cases
Posted by Mrinal Wadhwa <mr...@gmail.com>.
I don't have a lot of experience automating tests for HTML/JS code ... but I
know a lot of people use Selenium http://seleniumhq.org/
_
Mrinal
On Tue, Nov 10, 2009 at 1:47 PM, Richard Hirsch <hi...@gmail.com>wrote:
> But the question is how to do perform the UI tests during the build
> process. It is also possible for each developer to test the UI locally
> before the commits but this is very inefficient.
>
> D
>
>
> On Tue, Nov 10, 2009 at 9:11 AM, Vassil Dichev <vd...@apache.org> wrote:
> > Tests and documentation are definitely priority No.1 for me for the
> > next couple of months.
> >
> > From my previous experience with Cactus the framework starts the
> > container and connects to the test runner inside the container, which
> > then has all the contexts it needs. We are already doing the same
> > thing by running an embedded Jetty server, so I think we don't need
> > it.
> >
> > Vassil
> >
> >
> > On Tue, Nov 10, 2009 at 10:02 AM, Richard Hirsch <hi...@gmail.com>
> wrote:
> >> Based on the fact that I made a build yesterday that led to a
> >> non-functional app on stax, I started to think about tests in general
> >> and the fact that we will soon need more tests to have some degree of
> >> quality assurance.
> >>
> >> I've started a wiki page
> >> (http://cwiki.apache.org/confluence/display/ESME/Tests) with test
> >> cases.
> >>
> >> Ideally, we should have some sort of a test driver that tests the UI
> >> as well during the build process. If I remember correctly, cactus has
> >> something like this. I'll take a look and see if I find something that
> >> we can use.
> >>
> >> D.
> >>
> >
>
Re: Test Cases
Posted by David Pollak <fe...@gmail.com>.
On Tue, Nov 10, 2009 at 6:54 AM, Richard Hirsch <hi...@gmail.com>wrote:
> David: since today is your ESME day, could you look at Jira items
> "ESME-105: Add password-related functionality" and "ESME-111: :OpenID
> login/signon is broken" as well
>
Your ticket is my command.
>
> Thanks.
>
> D.
>
> On Tue, Nov 10, 2009 at 3:19 PM, David Pollak
> <fe...@gmail.com> wrote:
> > On Tue, Nov 10, 2009 at 12:17 AM, Richard Hirsch <hirsch.dick@gmail.com
> >wrote:
> >
> >> But the question is how to do perform the UI tests during the build
> >> process. It is also possible for each developer to test the UI locally
> >> before the commits but this is very inefficient.
> >>
> >
> > Do you have a ticket open for this? Today's my ESME day (once I get the
> > kids to school) and I would be interested in writing a few Lift testkit
> > examples (folks on the Lift list have been asking for them).
> Specifically,
> > testkit is (supposed) to be wired to certain hints that are emitted as
> part
> > of running the code in test mode so that it's (1) faster than selenium
> but
> > (2) it still goes through the container (an instance of Jetty is started)
> so
> > that you're getting a full-stack test (well, except for the JavaScript,
> > which requires the likes of selenium).
> >
> >
> >>
> >> D
> >>
> >>
> >> On Tue, Nov 10, 2009 at 9:11 AM, Vassil Dichev <vd...@apache.org>
> wrote:
> >> > Tests and documentation are definitely priority No.1 for me for the
> >> > next couple of months.
> >> >
> >> > From my previous experience with Cactus the framework starts the
> >> > container and connects to the test runner inside the container, which
> >> > then has all the contexts it needs. We are already doing the same
> >> > thing by running an embedded Jetty server, so I think we don't need
> >> > it.
> >> >
> >> > Vassil
> >> >
> >> >
> >> > On Tue, Nov 10, 2009 at 10:02 AM, Richard Hirsch <
> hirsch.dick@gmail.com>
> >> wrote:
> >> >> Based on the fact that I made a build yesterday that led to a
> >> >> non-functional app on stax, I started to think about tests in general
> >> >> and the fact that we will soon need more tests to have some degree of
> >> >> quality assurance.
> >> >>
> >> >> I've started a wiki page
> >> >> (http://cwiki.apache.org/confluence/display/ESME/Tests) with test
> >> >> cases.
> >> >>
> >> >> Ideally, we should have some sort of a test driver that tests the UI
> >> >> as well during the build process. If I remember correctly, cactus has
> >> >> something like this. I'll take a look and see if I find something
> that
> >> >> we can use.
> >> >>
> >> >> D.
> >> >>
> >> >
> >>
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Surf the harmonics
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Re: Test Cases
Posted by Richard Hirsch <hi...@gmail.com>.
David: since today is your ESME day, could you look at Jira items
"ESME-105: Add password-related functionality" and "ESME-111: :OpenID
login/signon is broken" as well
Thanks.
D.
On Tue, Nov 10, 2009 at 3:19 PM, David Pollak
<fe...@gmail.com> wrote:
> On Tue, Nov 10, 2009 at 12:17 AM, Richard Hirsch <hi...@gmail.com>wrote:
>
>> But the question is how to do perform the UI tests during the build
>> process. It is also possible for each developer to test the UI locally
>> before the commits but this is very inefficient.
>>
>
> Do you have a ticket open for this? Today's my ESME day (once I get the
> kids to school) and I would be interested in writing a few Lift testkit
> examples (folks on the Lift list have been asking for them). Specifically,
> testkit is (supposed) to be wired to certain hints that are emitted as part
> of running the code in test mode so that it's (1) faster than selenium but
> (2) it still goes through the container (an instance of Jetty is started) so
> that you're getting a full-stack test (well, except for the JavaScript,
> which requires the likes of selenium).
>
>
>>
>> D
>>
>>
>> On Tue, Nov 10, 2009 at 9:11 AM, Vassil Dichev <vd...@apache.org> wrote:
>> > Tests and documentation are definitely priority No.1 for me for the
>> > next couple of months.
>> >
>> > From my previous experience with Cactus the framework starts the
>> > container and connects to the test runner inside the container, which
>> > then has all the contexts it needs. We are already doing the same
>> > thing by running an embedded Jetty server, so I think we don't need
>> > it.
>> >
>> > Vassil
>> >
>> >
>> > On Tue, Nov 10, 2009 at 10:02 AM, Richard Hirsch <hi...@gmail.com>
>> wrote:
>> >> Based on the fact that I made a build yesterday that led to a
>> >> non-functional app on stax, I started to think about tests in general
>> >> and the fact that we will soon need more tests to have some degree of
>> >> quality assurance.
>> >>
>> >> I've started a wiki page
>> >> (http://cwiki.apache.org/confluence/display/ESME/Tests) with test
>> >> cases.
>> >>
>> >> Ideally, we should have some sort of a test driver that tests the UI
>> >> as well during the build process. If I remember correctly, cactus has
>> >> something like this. I'll take a look and see if I find something that
>> >> we can use.
>> >>
>> >> D.
>> >>
>> >
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
Re: Test Cases
Posted by Ethan Jewett <es...@gmail.com>.
I would love to see even 1 or 2 examples of this. I have not been able
to make sense of the Lift test classes and the great Google didn't
show me any examples on the first page :-( I would like to incorporate
actual HTTP requests to the Jetty server into the API test cases and
it sounds like that is an element of what you're talking about.
Ethan
On Tue, Nov 10, 2009 at 9:19 AM, David Pollak
<fe...@gmail.com> wrote:
> On Tue, Nov 10, 2009 at 12:17 AM, Richard Hirsch <hi...@gmail.com>wrote:
>
>> But the question is how to do perform the UI tests during the build
>> process. It is also possible for each developer to test the UI locally
>> before the commits but this is very inefficient.
>>
>
> Do you have a ticket open for this? Today's my ESME day (once I get the
> kids to school) and I would be interested in writing a few Lift testkit
> examples (folks on the Lift list have been asking for them). Specifically,
> testkit is (supposed) to be wired to certain hints that are emitted as part
> of running the code in test mode so that it's (1) faster than selenium but
> (2) it still goes through the container (an instance of Jetty is started) so
> that you're getting a full-stack test (well, except for the JavaScript,
> which requires the likes of selenium).
>
>
>>
>> D
>>
>>
>> On Tue, Nov 10, 2009 at 9:11 AM, Vassil Dichev <vd...@apache.org> wrote:
>> > Tests and documentation are definitely priority No.1 for me for the
>> > next couple of months.
>> >
>> > From my previous experience with Cactus the framework starts the
>> > container and connects to the test runner inside the container, which
>> > then has all the contexts it needs. We are already doing the same
>> > thing by running an embedded Jetty server, so I think we don't need
>> > it.
>> >
>> > Vassil
>> >
>> >
>> > On Tue, Nov 10, 2009 at 10:02 AM, Richard Hirsch <hi...@gmail.com>
>> wrote:
>> >> Based on the fact that I made a build yesterday that led to a
>> >> non-functional app on stax, I started to think about tests in general
>> >> and the fact that we will soon need more tests to have some degree of
>> >> quality assurance.
>> >>
>> >> I've started a wiki page
>> >> (http://cwiki.apache.org/confluence/display/ESME/Tests) with test
>> >> cases.
>> >>
>> >> Ideally, we should have some sort of a test driver that tests the UI
>> >> as well during the build process. If I remember correctly, cactus has
>> >> something like this. I'll take a look and see if I find something that
>> >> we can use.
>> >>
>> >> D.
>> >>
>> >
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
Re: Test Cases
Posted by David Pollak <fe...@gmail.com>.
On Tue, Nov 10, 2009 at 12:17 AM, Richard Hirsch <hi...@gmail.com>wrote:
> But the question is how to do perform the UI tests during the build
> process. It is also possible for each developer to test the UI locally
> before the commits but this is very inefficient.
>
Do you have a ticket open for this? Today's my ESME day (once I get the
kids to school) and I would be interested in writing a few Lift testkit
examples (folks on the Lift list have been asking for them). Specifically,
testkit is (supposed) to be wired to certain hints that are emitted as part
of running the code in test mode so that it's (1) faster than selenium but
(2) it still goes through the container (an instance of Jetty is started) so
that you're getting a full-stack test (well, except for the JavaScript,
which requires the likes of selenium).
>
> D
>
>
> On Tue, Nov 10, 2009 at 9:11 AM, Vassil Dichev <vd...@apache.org> wrote:
> > Tests and documentation are definitely priority No.1 for me for the
> > next couple of months.
> >
> > From my previous experience with Cactus the framework starts the
> > container and connects to the test runner inside the container, which
> > then has all the contexts it needs. We are already doing the same
> > thing by running an embedded Jetty server, so I think we don't need
> > it.
> >
> > Vassil
> >
> >
> > On Tue, Nov 10, 2009 at 10:02 AM, Richard Hirsch <hi...@gmail.com>
> wrote:
> >> Based on the fact that I made a build yesterday that led to a
> >> non-functional app on stax, I started to think about tests in general
> >> and the fact that we will soon need more tests to have some degree of
> >> quality assurance.
> >>
> >> I've started a wiki page
> >> (http://cwiki.apache.org/confluence/display/ESME/Tests) with test
> >> cases.
> >>
> >> Ideally, we should have some sort of a test driver that tests the UI
> >> as well during the build process. If I remember correctly, cactus has
> >> something like this. I'll take a look and see if I find something that
> >> we can use.
> >>
> >> D.
> >>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Re: Test Cases
Posted by Richard Hirsch <hi...@gmail.com>.
But the question is how to do perform the UI tests during the build
process. It is also possible for each developer to test the UI locally
before the commits but this is very inefficient.
D
On Tue, Nov 10, 2009 at 9:11 AM, Vassil Dichev <vd...@apache.org> wrote:
> Tests and documentation are definitely priority No.1 for me for the
> next couple of months.
>
> From my previous experience with Cactus the framework starts the
> container and connects to the test runner inside the container, which
> then has all the contexts it needs. We are already doing the same
> thing by running an embedded Jetty server, so I think we don't need
> it.
>
> Vassil
>
>
> On Tue, Nov 10, 2009 at 10:02 AM, Richard Hirsch <hi...@gmail.com> wrote:
>> Based on the fact that I made a build yesterday that led to a
>> non-functional app on stax, I started to think about tests in general
>> and the fact that we will soon need more tests to have some degree of
>> quality assurance.
>>
>> I've started a wiki page
>> (http://cwiki.apache.org/confluence/display/ESME/Tests) with test
>> cases.
>>
>> Ideally, we should have some sort of a test driver that tests the UI
>> as well during the build process. If I remember correctly, cactus has
>> something like this. I'll take a look and see if I find something that
>> we can use.
>>
>> D.
>>
>
Re: Test Cases
Posted by Vassil Dichev <vd...@apache.org>.
Tests and documentation are definitely priority No.1 for me for the
next couple of months.
>From my previous experience with Cactus the framework starts the
container and connects to the test runner inside the container, which
then has all the contexts it needs. We are already doing the same
thing by running an embedded Jetty server, so I think we don't need
it.
Vassil
On Tue, Nov 10, 2009 at 10:02 AM, Richard Hirsch <hi...@gmail.com> wrote:
> Based on the fact that I made a build yesterday that led to a
> non-functional app on stax, I started to think about tests in general
> and the fact that we will soon need more tests to have some degree of
> quality assurance.
>
> I've started a wiki page
> (http://cwiki.apache.org/confluence/display/ESME/Tests) with test
> cases.
>
> Ideally, we should have some sort of a test driver that tests the UI
> as well during the build process. If I remember correctly, cactus has
> something like this. I'll take a look and see if I find something that
> we can use.
>
> D.
>