Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ericduran’s picture

Just started, nothing there yet just the skeleton.

ericduran’s picture

Priority: Normal » Major

I have some local test written, need to update patch, still not ready and I'm waiting for the last critical issue to be fixed before we starting enforcing test.

ksenzee’s picture

I also have some local tests written. They're probably a lot the same. Should I go ahead and upload a patch, or wait?

ericduran’s picture

@ksenzee feel free to upload a patch, I'm waiting for #1212930: Convert the fivestar widget to use the D7 AJAX framework to get in, because that's going to break every test :)

ksenzee’s picture

Status: Active » Needs review
FileSize
3.48 KB

I just wrote a couple of tests that don't touch ajax yet for that very reason. Here they are. I suppose they might change when that issue gets in, but that issue needs tests anyway (which I am happy to write) so I don't think adding this to the codebase would hurt anything.

ericduran’s picture

@ksenzee Thanks, I'm testing this now, This is great start., I need to send Acquia a gift basket ;)

ksenzee’s picture

Heh. Other way around, I think. You've put up with our patches stacked up higher than a Jenga game. :)

ericduran’s picture

Speaking of patches :) This is now fixed. I committed the patch above with changes required to meet the new instance settings.

http://drupalcode.org/project/fivestar.git/commit/5028ee587df103f47e72c5...

I'm leaving this active for now while I add the ajax text.

ericduran’s picture

This one text that the proper ajax command is returned -- http://drupalcode.org/project/fivestar.git/commit/2bb3771

Still need to test the data in the ajax command.

As always more test are always welcome. I'm going to keep this issue open for a while, so we can keep adding test and attributing it to this issue.

ericduran’s picture

Status: Needs review » Fixed

Closing this issue out. I added another set of test. I think for now this issue isn't needed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

msonnabaum’s picture

Status: Closed (fixed) » Needs review
FileSize
583 bytes

Opening this backup since 4f5a61d59b475a6a13f7eeeabac0236ee4cb74bb points here.

The comment introduced says:

// TODO: why does passing in NULL works, yet passing in the actual form-id doesn't work.

I think that's because the old version was doing:

drupal_process_form($form_state['form_id'], $form, $form_state);

instead of:

drupal_process_form($form_state['values']['form_id'], $form, $form_state);

I have no idea what's actually happening here, I just saw the php notice for $form_state['form_id'], which didnt exist, and would explain why it didnt work before.

ericduran’s picture

Thanks, Even though the correct param should actually be $form['#form_id'] but they should be the same.

I'll fix this.

ericduran’s picture

For the test-bot

ericduran’s picture

Status: Needs review » Fixed

@msonnabaum Thanks.

I committed your patch with proper attribution then my param change on top of it. I like doing things in the proper order ;-)

--
http://drupalcode.org/project/fivestar.git/commit/5291166
http://drupalcode.org/project/fivestar.git/commit/c1e58cd

ericduran’s picture

Status: Fixed » Active

Actually opening this back up. I'm not sure it's worth processing the form, just for the single element.

ericduran’s picture

FileSize
877 bytes

Yet another patch, this one takes a different approach and removes the entire form process.

I'll need to try and remember why this is happening but it seems like it could be cleaned up a bit.

Uploading patch to see if it passes the test.

ericduran’s picture

Status: Active » Needs review
ericduran’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.