The ApplicationStateManager is injected by TapestryModule.class you will
either need to add this module to the registry or mock the service in a
test module (eg using mockito). Or, you might choose to split your own
module into smaller logical groups (eg core and web) for easier testing.
You might
yes. I actually sorted the problem. I had forgotten to include servet api as
a provided dependency in my pom.xml.
Thanks Mark.
Julien.
2011/7/14 Mark
> Do you actually have a page in com.cheetah.web.pages that is called
> CreateJobPosting that you can view in a web browser when the app is
> runn
Do you actually have a page in com.cheetah.web.pages that is called
CreateJobPosting that you can view in a web browser when the app is
running?
Mark
On Tue, Jul 12, 2011 at 12:11 PM, Julien Martin wrote:
> *public class CreateJobPosting{
>
> @Test
> public void test1() {
> String
igueiredo"
To: "Tapestry users" , "P Stavrinides"
Sent: Monday, 20 June, 2011 14:52:06 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: Unit testing mixins
On Mon, 20 Jun 2011 04:22:27 -0300, wrote:
> Hi Inge, Thiago,
Hi!
> Firstly, Thanks
Hi
The best way to learn testing tapestry is by reading the tests present in
the source code. Also, I learned a lot from the test written in chenillekit.
Hope it helps
regards
Taha
On Mon, Jun 20, 2011 at 5:22 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Mon, 20 Jun 2011
On Mon, 20 Jun 2011 04:22:27 -0300, wrote:
Hi Inge, Thiago,
Hi!
Firstly, Thanks guys for your replies!
I was aware of Jasmine, but not JsTestDriver... together they look very
promising (powerful) for unit tests. I think I will give them a go.
You're welcome!
As for Selenium, we had use
maintenance this time.
Thanks again!
Peter
- Original Message -
From: "Inge Solvoll"
To: "Tapestry users"
Sent: Friday, 17 June, 2011 13:11:12 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: Unit testing mixins
As long as your JS code is clean with low coupli
As long as your JS code is clean with low coupling, I think the best
solution is to do pure JS testing.
I've done a lot of this. Used Jasmine BDD for testing the javascript code.
Very nice testing framework that works both in the browser and headless,
from Jenkins/Hudson.
http://pivotal.github.co
On Thu, 16 Jun 2011 08:43:28 -0300, wrote:
Hi all,
Hi!
We are converting most of our JavaScript code in our Tapestry
applications into mixins, and I was wandering if anyone can recommend a
testing framework / methodology for unit testing these mixins.
I use JUnit (it could be TestNG or
If you are not using a (JPA) EntityManager or Tapestry's Hibernate
integration, you need to let Hibernate know about the entities
yourself. If you are really only testing the DAOs, you shouldn't need
to power up the IoC registry. Here's an excerpt of my persistence test
base class (with Mockito):
On 2/4/11 1:49 PM, matt...@mustardgrain.com wrote:
On 2/4/11 1:45 PM, Thiago H. de Paula Figueiredo wrote:
On Fri, 04 Feb 2011 19:37:03 -0200, matt...@mustardgrain.com
wrote:
Hello,
Hi!
org.hibernate.MappingException: Unknown entity:
com.mustardgrain.clientdailyupdate.entities.User
even
On 2/4/11 1:45 PM, Thiago H. de Paula Figueiredo wrote:
On Fri, 04 Feb 2011 19:37:03 -0200, matt...@mustardgrain.com
wrote:
Hello,
Hi!
org.hibernate.MappingException: Unknown entity:
com.mustardgrain.clientdailyupdate.entities.User
even though I'm using the import javax.persistence.Entit
On Fri, 04 Feb 2011 19:37:03 -0200, matt...@mustardgrain.com
wrote:
Hello,
Hi!
org.hibernate.MappingException: Unknown entity:
com.mustardgrain.clientdailyupdate.entities.User
even though I'm using the import javax.persistence.Entity annotation.
You'll probably need to add your AppMod
> I'm looking at the Testify framework, and while it looks promising, it
still
> doesn't connect up the spring layer.
>
> It also puts a /foo in front of every asset and page link on my page.
> Frustrating
The "/foo" is a default context that Tapestry adds when using its testing
features.
I'm looking at the Testify framework, and while it looks promising, it still
doesn't connect up the spring layer.
It also puts a /foo in front of every asset and page link on my page.
Frustrating
--
View this message in context:
http://old.nabble.com/Unit-testing-with-tapestry-5.1-and-spr
Thanks for mentioning TestBase. I like the set() method to push values into
private fields.
You are certainly right about that @Parameter is about the interaction with
the container of the component and should be tested via an integration test.
Thanks again.
Stephan
-
--
http://www.caimit
My thoughts are that @Parameter annotation represents an integration
between the component and its immediate container or other part of the
system. @Parameter(required=true) failures will show up in
integration tests.
In the rare event that I unit test an individual component, I just use
the faci
Hey,
I am running into the same problem.
Since PageTester now accepts extra module classes, I tried using
SpringModuleDef.class but no dice.
Creating a separate module as shown in previous posts didn't work either :-(
Does anybody have a working example with T 5.0.13+?
Cheers,
/Serge
Toby H
Many thanks, that's a huge help - I've got everything just where I need
it now.
-Original Message-
From: Joel Wiegman [mailto:[EMAIL PROTECTED]
Sent: 11 December 2007 15:45
To: Tapestry users
Subject: RE: unit testing
Tony,
The purpose of unit testing is to run your tests
Tony,
The purpose of unit testing is to run your tests in a black box
environment. If you auto-load all of the Spring configurations from
your web.xml and use them, you're kind of defeating the purpose of unit
testing.
If you're looking for integration testing (which it sounds like you
are), the
I would tend to use a mock IComponentSpecification, or a hand initialized
one.
There are not any magic tools here, though I suspect a lot of the plumbing
could be moved into base classes or helper classes.
On 6/4/07, carlos f <[EMAIL PROTECTED]> wrote:
Howard Lewis Ship wrote:
>
> But an int
Howard Lewis Ship wrote:
>
> But an integration test (either relatively contained, such as creating the
> EnhancementOperationImpl, or wider, such as firing up the app and testing
> with selenimum) is the only worthwhile way to
> ensure that generated code is correct.
>
I would like to as tigh
To be honest, I've been moving away from testing the actual code generation
towards your later observation, the create the class with the enhanced code
and see that it works.
To me that's a general maxum: with code generation, testing the generated
source isn't useful, testing the generated compi
Thanks for you advice. I think I'm a bit further forward.
viewProductDetail is actually a Tapestry component and is instantiated
using the com.javaforge.tapestry.testng.TestBase; library.
I have removed the expect call from my testGetSaving method and moved
the replay/verify to my setUp metho
Hmm .I can't pinpoint the exact problem but if it were up to me I would
start out by changing things to look more like:
public void setUp() {
...
webRequest = createMock(WebRequest.class);
expect(webRequest.getSession(true)).andReturn(webSession);
...
}
public void testGetSaving
Hi,
Thanks for you quick reply.
Sorry, my fault, I must have deleted these while removing my sysouts for
this post.
I have tried using these but unfortunately receive the same exception. I
have also done several searches on google, which seems to suggest the
exception is caused by the omiss
You still need to call the replay() / verify() easymock methods, which can
be examined further here:
http://easymock.org/EasyMock2_2_Documentation.html
I think getSession(boolean) also returns a value - so you'd have to define
what that return value is with a statement like:
expect(webRequest.g
27 matches
Mail list logo
