With the magic of “mocks,” we can test whether a database was accessed and how it was accessed. Think of a database update or an external http request. Side effects are things that often happen at a distance. How do you test a side effect? And what exactly is a side effect anyway? And why should I care? Typical OOP code does either or both at the same time. Functions return values and procedures have side effects. OOP embraces functions and procedures without distinction. And assertions are great for verifying values. Unit tests are generally reasoned about in terms of assertions. Since our method testableRelateOppToForecast() returns no value, how can we tell whether the relationship was created or not? Testing for Both Behavior and Assertion For example, if $this->bean→region_c is empty or $this->bean→expected_close_c is empty, no relationship should be created. However, some things will be more difficult to test as the code stands at present.
This is good in that our changes so far are likely to cause no damage.
Notice that we have not really changed the original code in any substantial way. We’ve completed the process of making our logic hook testable, so let’s start testing! In this part we will create a test suite for our refactored logic hook. Part 1 showed how to make an untestable logic hook testable in 5 easy steps. This is Part 2 of a series on how to test SugarCRM logic hooks.
0 kommentar(er)
