://www.laughingpanda.org/~inhuman/wicket-bench/docs/features-0.5.html
-Original Message-
From: Marko Sibakov [mailto:marko.siba...@ri.fi]
Sent: Monday, May 11, 2009 11:22 AM
To: users@wicket.apache.org
Subject: Re: 60% waste
Martin Grigorov wrote:
I'm using quite successfully WebDriver
On a side note, does Selenium even work with wicket?
Douglas
-Original Message-
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
Sent: Monday, May 11, 2009 12:13 AM
To: users@wicket.apache.org
Subject: Re: 60% waste
unit testing is about testing small isolated bits of functionality
, 2009 12:13 AM
To: users@wicket.apache.org
Subject: Re: 60% waste
unit testing is about testing small isolated bits of functionality in
isolation
lets say that you want to test foo(p) { return a(b(c(p))); }
what martin is trying to do is to test that foo(q) yields the desired
value w
Hi Martin!
I also found using paths to identify components really cumbersome in
test-driving wicket. I took a look at jdave-wicket and really liked its
approach. However, I didn't want to use jdave libs with my current project.
Inspired with this lib, I wrote this little snippet of code, which i
Tnx. But I am verry happy with my new beanz design ;)
**
Martin
2009/5/11 Krzysztof Jelski kjel...@gmail.com:
Hi Martin!
I also found using paths to identify components really cumbersome in
test-driving wicket. I took a look at jdave-wicket and really liked its
approach. However, I didn't
I thought there was a problem with wicket's random generation of ids.
D./
-Original Message-
From: Martin Grigorov [mailto:mcgreg...@e-card.bg]
Sent: Monday, May 11, 2009 7:15 AM
To: users@wicket.apache.org
Subject: RE: 60% waste
I'm using quite successfully WebDriver (a.k.a. Selenium 2
Subject: RE: 60% waste
I thought there was a problem with wicket's random generation of ids.
D./
-Original Message-
From: Martin Grigorov [mailto:mcgreg...@e-card.bg]
Sent: Monday, May 11, 2009 7:15 AM
To: users@wicket.apache.org
Subject: RE: 60% waste
I'm using quite successfully WebDriver
I thought there was a problem with wicket's random generation of ids.
The beanz overcomes that ;)
**
Martin
D./
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail:
with wicket ids and using
Selenium?
Was this fixed in v2 (WebDriver)?
D/
-Original Message-
From: Douglas Ferguson [mailto:doug...@douglasferguson.us]
Sent: Monday, May 11, 2009 9:38 AM
To: users@wicket.apache.org; mcgreg...@e-card.bg
Subject: RE: 60% waste
I thought
anybody had problems with wicket ids and using
Selenium?
Was this fixed in v2 (WebDriver)?
D/
-Original Message-
From: Douglas Ferguson [mailto:doug...@douglasferguson.us]
Sent: Monday, May 11, 2009 9:38 AM
To: users@wicket.apache.org; mcgreg...@e-card.bg
Subject: RE: 60% waste
I
...@gmail.com]
Sent: Monday, May 11, 2009 12:13 AM
To: users@wicket.apache.org
Subject: Re: 60% waste
unit testing is about testing small isolated bits of functionality in isolation
lets say that you want to test foo(p) { return a(b(c(p))); }
what martin is trying to do is to test that foo(q) yields
Related wiki entry
http://cwiki.apache.org/confluence/display/WICKET/Type-safe+testing+in+wicket
**
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail:
Ben Tilford wrote:
Have you looked at selenium? Your not really unit testing here.
Hi Ben,
What do you mean Your not really unit testing here. ?
MSi
On Sat, May 9, 2009 at 7:41 AM, Marko Sibakov marko.siba...@ri.fi wrote:
Like Martijn said i also strongly recommend to take a look at
unit testing is about testing small isolated bits of functionality in isolation
lets say that you want to test foo(p) { return a(b(c(p))); }
what martin is trying to do is to test that foo(q) yields the desired
value w, what he should do instead is
test a() in isolation to make sure it works
Hi!
What about if the MarkupContainer was used in a more bean-like manner:
public abstract class ListItemT extends WebMarkupContainer ...
new ListViewMyData(id, ..., MyListItem.class);
public class MyListItem extends ListItemMyData {
private TextField myTextField;
public MyListItem(MyData
Ofcourse I forgot the getter...
public class MyListItem extends ListItemMyData {
private TextField myTextField;
public MyListItem(MyData myData) {
myTextField = TextField(...);
}
/**
* @return the myTextField
*/
public TextField getMyTextField() {
return myTextField;
}
Martin Makundi schrieb:
Interesting. I googled for printDoc Wicket but did not find anything.
Where is that utility?
public void printDocument() {
System.out.println(tester.getServletResponse().getDocument());
}
**
Martin
Like Martijn said i also strongly recommend to take a look at the
jdave-wicket's selectors (http://www.jdave.org/).
examples =
http://svn.laughingpanda.org/svn/jdave/trunk/jdave-wicket/src/test/jdave/wicket/PageWithItemsSpec.java
with form tester it goes like this =
form =
Have you looked at selenium? Your not really unit testing here.
On Sat, May 9, 2009 at 7:41 AM, Marko Sibakov marko.siba...@ri.fi wrote:
Like Martijn said i also strongly recommend to take a look at the
jdave-wicket's selectors (http://www.jdave.org/).
examples =
Hi!
I have now better formalized my intentions (couldn't get sleep because
of this ;). You can see the benefits for yourself. However, I found
out that most of it can be done with existing wicket. Maybe some part
of the philosophy could be adapted into wicket in general. I submitted
a quickstart
See jdave-wicket for better test support. Slated to come to you in Wicket 1.5
Martijn
On Fri, May 8, 2009 at 5:48 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Hi!
I use TDD: I spend 60% of my time type-checking and path-checking my
wicketTests and components.
I always have
Martin Makundi ha scritto:
Hi!
I use TDD: I spend 60% of my time type-checking and path-checking my
wicketTests and components.
I always have the wrong path and I must prinDocument and iterate to
get it right
I don't know if this is of any help, but I've written the attached
utility
I don't know if this is of any help, but I've written the attached
utility class that, given a component, can print its containment
structure, along with the eventual component classes and
model values (toString-ed).
Well... printDoc and wicket
getDebugSettings().setOutputComponentPath(true);
you should really use visitors for this kind of thing...something like
this may work very well for you
TestUtils.attachTestId(Component c, String id) {
if (application.get().getconfigurationtype()!=production) {
c.setmatadata(testkey, id);
}
}
then in your code
Form form=new Form(..);
you can also create a test panel that contains just your form and test
that instead of creating the entire complex page just to test the
form. break your tests into small units and test in isolaton. your
test harness panel can have a getter that gives you direct access the
the form you are
Well, strings all over the place, if I get what you mean.
But I write the tests first and they define what the paths and ids
should be and Wicket is really quick about discovering when the
implementation doesn't follow spec (i.e. tests).
Doing a small step at a time takes you there faster.
you should really use visitors for this kind of thing...something like
this may work very well for you
I know that with more work I can make ... more work.
What I am looking for is a solution that makes it possible to have
intellisense while coding and compile-time type checking. Visitors
etc.
Use an IDE plugin?
On Fri, May 8, 2009 at 2:39 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
you should really use visitors for this kind of thing...something like
this may work very well for you
I know that with more work I can make ... more work.
What I am looking for is a
But I write the tests first and they define what the paths and ids
should be and Wicket is really quick about discovering when the
implementation doesn't follow spec (i.e. tests).
I concentrate on coding.. sometimes I write the implementation,
sometimes the tests, whichever goes faster until
Use an IDE plugin?
That's a hack, not a design.
**
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
so what you are saying is that adding one line of code to mark the
component you want to test, and then being able to find that component
easily in your test - independent of its place in hierarchy and
without relying on strings - is more work?
-igor
On Fri, May 8, 2009 at 11:39 AM, Martin
wicket component hierarchy is dynamic, so there is no predicting it at
compile time. this is one of the most powerful features of wicket.
-igor
On Fri, May 8, 2009 at 11:39 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
you should really use visitors for this kind of
What about introducing an xpath-ish like expression API that could
help you search for components within the hierarchy?
On Fri, May 8, 2009 at 3:07 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
wicket component hierarchy is dynamic, so there is no predicting it at
compile time. this is one
Martin Makundi wrote:
Use an IDE plugin?
That's a hack, not a design.
Wow...I'm new to this list, but I doubt you can expect much help with
that attitude. I suggest you request a refund for your Wicket license
and support subscription and go find a tool that better fits your needs.
Oh,
Martin Makundi ha scritto:
I don't know if this is of any help, but I've written the attached
utility class that, given a component, can print its containment
structure, along with the eventual component classes and
model values (toString-ed).
Well... printDoc and wicket
Interesting. I googled for printDoc Wicket but did not find anything.
Where is that utility?
public void printDocument() {
System.out.println(tester.getServletResponse().getDocument());
}
**
Martin
-
To unsubscribe,
wicket component hierarchy is dynamic, so there is no predicting it at
compile time. this is one of the most powerful features of wicket.
Yes but each component is always fixed relative to its parent. The
html markup fixes the hierarcy, so something might be devised here.
What about
37 matches
Mail list logo
