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
Anybody have the same experience?
How about introducing type-safety and path-safety/identity into
component h
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
wrote:
> 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 pri
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 class
> 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(tru
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 testing.
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.
"Let'
> 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
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 solution that makes it poss
> 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 Makund
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
wrote:
>> you should really use visitors for this kind of thing...something like
>> this may work very w
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 wrote:
> wicket component hierarchy is dynamic, so there is no predicting it at
> compile time. this is one of the most powerful fe
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, wait
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
getDebugSettings().setO
> 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 introdu
Hi!
What about if the MarkupContainer was used in a more bean-like manner:
public abstract class ListItem extends WebMarkupContainer ...
new ListView("id", ..., MyListItem.class);
public class MyListItem extends ListItem {
private TextField myTextField;
public MyListItem(MyData myData) {
Ofcourse I forgot the getter...
public class MyListItem extends ListItem {
private TextField myTextField;
public MyListItem(MyData myData) {
myTextField = TextField(...);
}
/**
* @return the myTextField
*/
public TextField getMyTextField() {
return myTextField;
}
}
20
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 = wick
Have you looked at selenium? Your not really "unit" testing here.
On Sat, May 9, 2009 at 7:41 AM, Marko Sibakov wrote:
> 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/
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 w
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: users-h...@wicket.apache.or
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 wrote:
Like Martijn said i also strongly recommend to take a look at the
jdave-wick
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
tes
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
il.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 mar
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 f
Tnx. But I am verry happy with my new beanz design ;)
**
Martin
2009/5/11 Krzysztof Jelski :
> 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 jd
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.
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
> 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: users-h...@w
ems 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
&
9:38 AM
>> To: users@wicket.apache.org; mcgreg...@e-card.bg
>> Subject: RE: 60% waste
>>
>> I thought there was a problem with wicket's random generation of ids.
>>
>> D./
>>
>> -Original Message-
>> From: Martin Grigorov [mailto:mcg
or.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 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) yi
://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 W
38 matches
Mail list logo
