Group items tagged

've been able to accomplish what you're doing with Selenium testing. If you're using GWT, then your integration testing and user acceptance probably won't be that far from each other.

> My question is this. What's the best way to use LocalServiceTestHelper > so that I can use my app like it has a persistent store? There is no > 'setUp' and 'tearDown' hooks like a JUnit test and the app runs in a > separate process within the IDE. (And in any case, I'm looking to do > integration testing where I want the state to be consistent across a > number of page requests.)

3. Adds a new gae:start goal. This is identical to gae:run, except that it does not automatically execute the package phase before starting the server. The intent is to use this in a project POM, but it can also be used to start the server quickly when you don't want to rebuild the project. Right now I just copied the RunGoal completely, except for the '@execute phase="package"' declaration, because I didn't want to introduce conflicts in case someone else is editing RunGoal.java. A better thing to do in the future would be to have RunGoal extend StartGoal with an empty class that just adds the '@execute phase="package"' annotation (it can't be the other way around, with StartGoal extending Run goal, because there's no way to override a mojo with an @execute annotation with one that doesn't have it---it gets inherited automatically).

The idea behind all of these changes is to make it so that you can use the maven-gae-plugin in a project's POM for automated integration tests. The gae:start goal automatically binds to the pre-integration-test phase by default, and the gae:stop goal binds to post-integration-test. This is most useful when combined with something like the maven-failsafe-plugin and a functional testing library like HtmlUnit that you can use to simulate web requests. It would also be useful for Selenium testing.

The GAE docs talk about how to setup a test to use the datastore.  But also follow the instructions here until the docs are fully updated.

 If you're following the how-to article on unit testing ( http://code.google.com/appengine/docs/java/howto/unittesting.html) you'll need to update your TestEnvironment class to look like this one: http://code.google.com/p/datanucleus-appengine/source/browse/branches... (lines 34 - 66) We're working on getting the docs updated right now.

there are few jars like appengine-testing.jar appengine-local-rutime-shared.jar etc. Basically when you create a new GAE project the eclipse plugin copies some jars automatically in war folder, which are required when you will be running ur application on GAE server, but it doesnt copy few test jars which are required only for local dev env and testing. So what i did i compared jars in my war folder and GAE SDK installed folder. I found that few of jars not included so i included all in my Eclipse build path/Junit run path(but didnt copy into war folder) and that worked for me and then i didnt care to check which were the jars actually needed and which were not as i included all jars. But somehow in docs they have mentioned to included only one or two jars and with these jars junit doesnt work.

   private LocalServiceTestHelper helper =          new LocalServiceTestHelper(new   LocalDatastoreServiceTestConfig().setBackingStoreLocation(DS_PATH)); You could copy the WEB-INF/appegine-generated/local_db.bin file with   your data next to your test case and in a @Before method, delete the   old copy and copy a new one to DS_PATH.  You might also want to check   out LocalDatastoreServiceTestConfig().setNoStrage(true)

for Java developers, there is a remote API handler available; adding following to your web xml file should work (disclaimer: I have not yet personally tested this.) <servlet>   <servlet-name>remoteapi</servlet-name>   <servlet-class>com.google.apphosting.utils.remoteapi.RemoteApiServlet</servlet-class> </servlet> <servlet-mapping>   <servlet-name>remoteapi</servlet-name>   <url-pattern>/remote_api</url-pattern> </servlet-mapping> <security-constraint>   <web-resource-collection>     <web-resource-name>remoteapi</web-resource-name>     <url-pattern>/remote_api</url-pattern>   </web-resource-collection>   <auth-constraint>     <role-name>admin</role-name>   </auth-constraint> </security-constraint>

'm guessing your tests were run locally because the counter in the local datastore does indeed have datastore scope.  The scope of the counter in the prod datastore, however, is parent key + kind.  This is described here: http://code.google.com/appengine/docs/java/datastore/creatinggettinga... If it's important to you that the scope of the generated ids match between dev and and prod please file an issue.

                StringBuffer sb = new StringBuffer();                 KeyRange range = ds.allocateIds("a", 2);                 for (Key key : range) {                         sb.append("\n a " + key.toString());                 }                 range = ds.allocateIds("b", 2);                 for (Key key : range) {                         sb.append("\n b " + key.toString());                 }                 Key parentKey = KeyFactory.createKey("c", 1);                 sb.append("\n c " + parentKey.toString());                 range = ds.allocateIds(parentKey, "d", 2);                 for (Key key : range) {                         sb.append("\n d " + key.toString());                 }                 System.out.println(sb.toString());

The URL I posted earlier in the thread explains it, but here's a little bit more detail: A parent entity plus a kind defines an id-space, so entities with the same parent and the same kind are guaranteed to have unique ids.  For example, if you have an Entity with Parent:A Kind: Person Id: 10 you are guaranteed that no other entity with Parent A and Kind Person will be assigned an Id of 10.  However, an entity with a different Parent and Kind Person or an entity with Parent A and a different Kind _can_ be assigned an Id of 10.  The datastore pre-allocates batches of ids across multiple servers under-the-hood, so you can't make any assumptions about the Id that will get assigned in terms of contiguousness.  The only safe assumption is that the id will be unique for that Parent/Kind combination.

I figure it is going to take me at least four iterations to get this right. The first one will be building a GWT application with a simple UI that has no server logic behind it (just to learn how layout in GWT works). Step two will be adding a fake servlet backend (not app engine, just in memory). While not exactly App Engine yet, I should have a completely specified client-server API by the end of this process that I can subsequently implement on App Engine (iteration 3). Iteration four will handle deployment, CSS and whatever I may screw up in iterations one and two. I will log my notes of things I run into while I code.

Google app engine uses the concept of static files. This is a performance optimization. Using the file appengine-web.xml you can configure the way google handles static files. You can include and exclude certain files using their extension or name. More information can be found here at google. This all works nice in the online version, however there seems to be a problem with the development server. Some solutions try to configure the local version as well, still that did not work for me. I decided to look for a servlet that serves static files.

That is it, now you can test your stuff locally and all your scripts, images, styles are loaded by your application. Of course you have to remove this servlet before uploading your application. Hope it helps people with their local debugging of jquery scripts or other javascript things.

Queries involving keys use indexes just like queries involving properties. Queries on keys require custom indexes in the same cases as with properties, with a couple of exceptions: inequality filters or an ascending sort order on __key__ do not require a custom index, but a descending sort order on __key__ does. As with all queries, the development web server creates appropriate configuration entries in this file when a query that needs a custom index is tested.