I intentionally left this out, as it's pretty much a copy/paste job from the product module with some special considerations for the fact that orders don't have order types. See commerce/modules/product/tests/commerce_product.test.

CommentFileSizeAuthor
#3 737810-1-commerce_order_crud_test.patch8.89 KBdpolant

Comments

bojanz’s picture

Assigned: Unassigned » bojanz

Will give it a shot this week.

rszrama’s picture

Assigned: bojanz » Unassigned
Status: Active » Postponed

I'm postponing this until we actually give unit testing some attention. As our 1.0 goal is full functional test coverage, adding CRUD API test coverage comparable to the tests found in commerce_product.test isn't really a priority item. We can revisit this later but focus on more immediate tasks for now.

dpolant’s picture

Status: Postponed » Needs review
StatusFileSize
new8.89 KB

I've provided a patch that adds CRUD and token-replace tests for orders. It is modeled after commerce_product.test. This my first time writing a unit test so it could probably use some review.

One thing I wasn't sure about: line 193 of commerce_product.test uses assertNotIdentical to check the edit-url token replacement for products. I'm not sure why we are checking that these values are not identical - is this a mistake? I copied this structure into the new commerce_order.test as it is.

In order to make order:hostname token replacement work, I added it to commerce.info.inc. Additionally, I added a method generateEmail to CommerceBaseTestCase to generate a random email.

Also, it's probably worth noting that commerce unit tests fail when using commerce kickstart if you don't move profiles/commerce_kickstart/modules/commerce into sites/all/modules.

rszrama’s picture

Status: Needs review » Fixed

As for the assertNotIdentical, it's because the assertion there is based on the usage of strpos(). This assertion will pass if the return value !== FALSE, meaning the integer 0 will still pass. This may in fact be the result of the token replacement (though I'm not sure if it necessarily will be, like if Drupal is being run in a subdirectory of the docroot), hence the assertNotIdentical to pass anything besides FALSE.

The hostname Entity API integration and new method on the base test class look fine. I won't nitpick over the tests too much, as they seem to cover the basics and all pass. Drupal doesn't really have a great framework for unit tests as is, but it's worth having these around in case we screw something up horribly. : )

Committed.

Status: Fixed » Closed (fixed)
Issue tags: -Simpletest, -low-hanging fruit

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