Testing SugarCRM Customizations

Posted 2012-08-09
Written by Matt Frost
Category code

Perhaps the hardest thing about Unit Testing SugarCRM customizations is that it's not a very common practice. The core code has some unit tests around it, I'll admit that I haven't really investigated the tests that exist for core product; because I haven't really had to interact with them at this point. The project in question here was using SugarCRM 6.3.1 and the feature I was trying to implement was actually really straight forward.  The idea behind it was essentially to take the values from a relate field and store them as a many-to-many relationship so they appeared in both modules subpanel.

Something Wasn't Right

As I wrote the test code to create the opportunity and run through the logic hooks I had written, there were some weird things going on. At first, the retrieve method was returning null. I knew the Opportunity existed because I was creating right there. Yet when I would create, save, retrieve the retrieve was empty. So I looked through some of the other tests, found how to load the custom fields separately and was able to move on with my testing. When I wrote my logic hook and put it in the system, I started seeing Notices turn up as I'd run my tests. Things like "Undefined index: type" along with a stack trace of what was going on.

Time to debug

I went through the stack trace and noticed that it was happening on the add relationship method, I started following the trace through the layers of code. Type is a relatively commonly used key in a lot of systems, and SugarCRM is no different. I was certain it was a bug and that I was going to find it, submit it back to SugarCRM and feel really great about myself. Some time went by and that's not really what happened. What did happen, as I was leaving the office, was that I realized that there were a lot of non-db fields that we created very early on in this project. Since the type field was typically varchar, int and other database field types; I decided that I didn't need to provide that key in the definition. Sure enough, my suspicions were confirmed when I added a bit of debugging code to the SugarBean class. Here's a little taste of what I did above the line number in the stack trace.

foreach($this->field_defs as $field){
    if(!isset($field['type'])){
        var_dump($field);
        exit;
    }
}
I could have made this process a bit quicker perhaps by finding a way to get all the fields that were missing types, but to confirm that this is what was happening, it worked out perfectly.

Fixing

So I stepped through each field, found one fixed it, found another one fixed. All in all, there weren't but 5 or 6 fields total that required attention; but a relatively small detail like defining a field type for non-db field wreaked a healthy amount of havoc on my test. I have other tests in this same module, and none of the other tests caught this issue; which is why it really is important to test as many things as you can. As soon as I got all the fields fixed, did a quick Repair/Rebuild from the admin panel. My test started failing at my dummy assertion and I knew I had conquered it. I wrote the last pieces of my test to confirm that everything I thought was happening was indeed happening. I was correct! The feature was done, the tests were written and I had fixed some issues that I had forgotten about; really who knows when they could have cropped up and caused an emergency situation?

Extra Effort

Unit testing takes a bit of extra effort, I won't deny that. In fact, I was so frustrated and lost at one point that I convinced Jason Eggers to hop on a join.me session with me (which I'm grateful for) and we looked at the code and couldn't figure out what was going on. For as frustrated and defeating as it was, I learned a very important lesson today. The extra effort you put in to write the tests pays off in ways you don't always expect. It was a very simple logic hook, one that my old-self tried to convince my new self that I didn't need a test to implement. I'm glad I found more problems, I'm glad I was able to fix them and I'm glad I was able to add value to the software. If you have questions about Unit Testing with Sugar, I'm usually hanging out in #sugarcrm on Freenode; I'd be happy to talk or listen on the topic. I also tend to tweet quite a bit too. Let me know what you think!

Comments

There are no comments

Posting comments after has been disabled.