In my unit tests for my entities using HRD, I simply switch that percentage
completely on/off around those few places in the unit test code where I
need my entity to become "fully committed" in order for the rest of the
unit test to work. Yes, it is kind of contrived, but then again so is a
unit test. I must consciously decide to flip it on/off around that bit of
code. My unit test code looks something like this:


//read this:
http://code.google.com/appengine/docs/java/tools/localunittesting.html
public class SampleUnitTest {

private static boolean SHOULD_APPLY = false; // set this flag appropriately
in the units test below.
 private static final class CustomHighRepJobPolicy implements
HighRepJobPolicy {
@Override
public boolean shouldApplyNewJob(Key arg0) {
return SHOULD_APPLY;
}
@Override
public boolean shouldRollForwardExistingJob(Key arg0) {
return SHOULD_APPLY;
}
    }

private final LocalServiceTestHelper helper = new
LocalServiceTestHelper(new
LocalDatastoreServiceTestConfig().setAlternateHighRepJobPolicyClass(CustomHighRepJobPolicy.class));

    @Before
    public void setUp() {
        helper.setUp();
    }

    @After
    public void tearDown() {
        helper.tearDown();
    }


    @Test
    public void test1() throws Exception {
    String orgName = "The Organization, Inc.";
    SHOULD_APPLY = true; // temporarily allow things to be written to
datastore for real
final OOrganization org = ODaoOrganization.create(orgName);
    SHOULD_APPLY = false; // return HRD writes back to full "failure" for
remaining unit test

    // now do my unit test that needed my org entity to be properly
persisted.
    }
}


Broc



On Mon, Oct 31, 2011 at 3:36 PM, Jeff Schnitzer <j...@infohazard.org> wrote:

> There's this:
>
> https://groups.google.com/d/msg/google-appengine/NdUAY0crVjg/3fJX3Gn3cOYJ
>
> Some thoughts:
>
>  * I don't think there's really anything to save you from eventuality
> except careful consideration during the design of your data model.  Pick
> your entity groups carefully and use XG transactions sparingly to move data
> "across" when you need atomicity.
>
>  * A lot of the time eventuality is not a big deal. On the other hand, if
> you're building an accounting app, it probably is a big deal.
>
>  * There's a difference between what your users experience and what your
> tests experience.  Say you have a test for "add this product to the catalog
> and then check to see if it's in the catalog".  In the real world it
> doesn't matter if your users see the new product right away.  But your
> tests demand it immediately.  The problem is with the test.  I've "fixed"
> the tests by doing this in my fixture setup:
>
> newLocalDatastoreServiceTestConfig().setDefaultHighRepJobPolicyUnappliedJobPercentage(0.1f)
>
> Unfortunately a good argument can be made that this diminishes the value
> of the tests. Really some tests should be run with eventuality and others
> without.  Anyone know if setDefaultHighRepJobPolicyUnappliedJobPercentage()
> can be called repeatedly after setup to switch back and forth?
> Jeff
>
> On Mon, Oct 31, 2011 at 6:31 AM, Aswath Satrasala <
> aswath.satras...@gmail.com> wrote:
>
>> Hi,
>> I am trying HRD on local dev server.  I have bunch of webdriver tests for
>> different parts of my application that create entities and then doing a
>> list of all the entities.
>> My tests are failing in several places.  It is due to the eventual
>> consistency of the HRD.  The tests run fine on M/S and on both
>> production/local environment.
>> I have 20-30 KINDS, and entities are created for 1-or more KINDs
>> depending on the business logic, all in a transaction.   Immediately,
>> various reports are done.  They fail.
>>
>> My question: What pattern needs to be followed?  My application has grown
>> very large during last 1.5 years or so.  Doing re-factoring at every place
>> in the application for eventual consistency will be a very large effort for
>> a small team. I don't even know what extra work needs to be put to get this
>> fixed.
>>
>> Am I better of sticking with M/S.  So far, I have managed and designed
>> entity relationships to work within one entity group.
>>
>> Are there any patterns coming out from the Objectify team to handle
>> Eventual consistency issue of the HRD?
>>
>> -Aswath
>> www.AccountingGuru.in
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine for Java" group.
>> To post to this group, send email to
>> google-appengine-java@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine-java+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine-java?hl=en.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Reply via email to