You\u2019re a few months into writing a shiny new web app, and the team just settled on some new standards for data structures used for communication with the server.<\/p>\n
You\u2019ll need to refactor a few pages, but that\u2019s not a big deal. Your team has been pushing good unit testing practices, and you\u2019ve got great coverage for the affected code. You make the changes, verify that the unit tests still pass, maybe do a little manual testing for good measure, and then get everything committed.<\/p>\n
A few days later, the bug reports start rolling in. This column no longer shows the right data. When I run Test Case 5 the Widget Editor doesn\u2019t render correctly. The sort order for data on the home page is wrong.<\/p>\n
They\u2019re all for pages you modified, and nobody else has worked on those pages. You know your refactoring is to blame; but the unit tests were still passing! What the heck happened\u2026?<\/p>\n
In a strongly-typed language like Java, you probably rely heavily on a mock object framework. Through the magic of gclib the framework dynamically creates subclasses of your various services, repositories, etc. and serves up instances of those subclasses to replace each dependency used by your subject code.<\/p>\n
In JavaScript you don\u2019t need all that. In fact, you can\u2019t have all that, because nowhere do you definitively describe a \u201cclass\u201d for your objects. So your unit testing tool may provide some mocking support (like the \u201cspy\u201d functionality in Jasmine), but in general your unit tests can just build objects with whatever members they expect the subject code to access.<\/p>\n
Do you see the trap yet?<\/p>\n
Your app handles orders. An order has a list of line items (each with a part number, quantity, and unit cost), a shipping address, and a shipping fee. To simplify the example, all costs are in whole dollars.<\/p>\n
In Java you define the following classes:<\/p>\n
public class Order {\r\n\tprivate List<LineItem> lineItems;\r\n\tprivate Address shipTo;\r\n\tprivate int shippingFee;\r\n\r\n\t\/\/ getters and setters ...\r\n}\r\n\r\npublic class LineItem {\r\n\tprivate string partNumber;\r\n\tprivate int quantity;\r\n\tprivate int unitCost;\r\n\r\n\t\/\/ getters and setters ...\r\n}\r\n<\/pre>\nYou also have an OrderService with the following method:<\/p>\n
public int calculateTotalCost(Order order) {\r\n\tint result = order.getShippingFee();\r\n\tfor (LineItem lineItem : order.getLineItems()) {\r\n\t\tresult += lineItem.quantity * lineItem.unitCost;\r\n\t}\r\n\r\n\treturn result;\r\n}\r\n<\/pre>\nTo test the OrderService, you\u2019ll want to pass in Order instances with known cost values and check that the correct total is returned. A pure approach would use mock objects with scripted responses for the getters, but for simple data objects with \u201clogic-less\u201d getters and setters, you might elect to create real Order objects instead.<\/p>\n
(If the test needed to verify that specific Order methods were used along the way, we\u2019d have to use a mock regardless; but we just want to test for the correct result.)<\/p>\n
\r\nOrder order = new Order();\r\nList<LineItem> lineItems = new ArrayList<LineItem>();\r\nLineItem item1 = new LineItem();\r\n\r\nitem1.setQuantity(2);\r\nitem1.setUnitCost(42);\r\nlineItems.add(item1);\r\norder.setLineItems(lineItems);\r\norder.setShippingFee(37);\r\n\r\nint result = orderService.calculateTotalCost(order);\r\nassertEquals(121, result);\r\n<\/pre>\nMeanwhile, another team is putting together a proof-of-concept for a more JavaScript-centric architecture. Your Order class gets JSON bindings; the above test Order, for example, would serialize as:<\/p>\n
\r\n{ \"lineItems\": [\r\n \"partNumber\": \"XL123\"\r\n , \"quantity\": 2\r\n , \"unitCost\": 42\r\n ]\r\n, \"shipTo\": { \/*...*\/ }\r\n, \"shippingFee\": 37\r\n}\r\n<\/pre>\nThey have an orderService.js containing a JavaScript version of calculateTotalCost():<\/p>\n
\r\nvar calculateTotalCost = function (order) {\r\n\tvar result = order.shippingFee;\r\n\tfor (var i = 0; i < order.lineItems.length; i++) {\r\n\t\tvar lineItem = order.lineItems[i];\r\n\t\tresult += lineItem.quantity * lineItem.unitCost;\r\n\t}\r\n\r\n\treturn result;\r\n};\r\n<\/pre>\nThey unit test their JavaScript code with Jasmine. If they need to pass in a simple data object, they build it on the spot. (Alternately, they might include helper functions in their test scripts to build these sorts of object.)<\/p>\n
\r\ndescribe(\"calculateTotalCost()\", function () {\r\n\tit(\"gives the total cost including shipping\", function () { \r\n\t\tvar order = {\r\n\t\t\t orderItems: [{\r\n\t\t\t\t quantity: 2\r\n\t\t\t\t, unitCost: 42\r\n\t\t\t }]\r\n\t\t\t, shippingFee: 37\r\n\t\t};\r\n\t\tvar result = calculateTotalCost(order);\r\n\t\texpect(result).toEqual(121);\r\n\t});\r\n});\r\n<\/pre>\nNow while the proof-of-concept is being evaluated, this logic has to be maintained in two places; but both teams agree that the test coverage is good (meaning, presumably, that there are more tests than we\u2019ve shown here), so nobody\u2019s too worried.<\/p>\n
The Trap Is Sprung<\/h2>\n
Mid-way through the proof of concept period, you get a new requirement: Shipping costs need to be attributed to specific line items. The JavaScript team is off site, but you figure they can catch up; worst case their unit tests will alert them that something\u2019s broken, right?<\/p>\n
The Java team agrees that to avoid potential inconsistency, the shippingFee property will be removed from Order. There was some talk about minimizing interface changes by keeping the Order.getShippingFee() method (rewriting it to sum up the line items\u2019 shipping fee values), but everyone agrees that the order-level shipping fee should be removed from the JSON bindings in any case.<\/p>\n
You update the Java classes. The unit tests don\u2019t build since they reference nonexistent methods, so you fix them. Then you notice something weird\u2026<\/p>\n
The unit tests are passing. All of them. Even the JavaScript ones.<\/p>\n
The problem is that the JavaScript unit tests are making the same wrong assumptions about the Order structure as the code they\u2019re meant to test. In this case, it would likely get caught through even moderately good team communication; but in a bigger system, it\u2019s possible some code would slip through the cracks.<\/p>\n
And anyway, isn\u2019t the point of unit tests to alert you to a defect even if you somehow miss it<\/em>?<\/p>\nSo Where Should Mock Objects Come From<\/h2>\n
There are two ways to improve on this situation. Ideally we\u2019d like to remove assumptions about object structure from the unit test code. If we can\u2019t do that, maybe we can figure out how to validate those assumptions.<\/p>\n
In Java, our unit tests validate their assumptions about the structure of an order by trying to compile (and\/or run) against the Order and LineItem classes. In JavaScript, though, an object doesn\u2019t have a class.<\/p>\n
I noted above that the unit test scripts could contain helper functions for building data objects. We could make it a rule that all data objects must be obtained from helpers, and that the helpers must all be in a central library shared by all test scripts. Then updating that central library should cause all affected tests to fail. This would tend to isolate the assumptions in the test code. It does have its limitations. Ultimately our test codebase still contains unverified assumptions about the object structure, and there\u2019s no guarantee that each assumption can be isolated to a single helper function.<\/p>\n
Another option is to create an Order constructor. Of course, when we receive a JSON representation of an Order, it won\u2019t have gone through that constructor; so to make this meaningful, we have to use the received JSON to construct a \u201creal\u201d Order object that our code will operate on, and then throw the JSON representation away.<\/p>\n
At a glance, this feels wasteful; but then at some point in history many of the conventions we use to promote testability and maintainability were received with the same criticism. As a side benefit, our constructed object could use closures to conceal the internal state and provide access through getters and setters, providing some of the encapsulation we had in the Java world.<\/p>\n
When we first got the new requirement that changed our definition of an Order, we\u2019d update the Order constructor unit tests accordingly, which would lead us to fix the Order constructor itself. Once the constructor is fixed, our unit tests would fail when trying to call setShippingFee() on the order, much like the Java case, and we\u2019d have test failures pointing to each bit of code we need to fix.<\/p>\n
Final Thoughts<\/h2>\n
This is likely not the only solution, and it may not be the best one; let us know how you\u2019ve addressed this issue in the comments below.<\/p>\n
Regardless, this should serve as a reminder that languages like JavaScript give us more than enough rope to hang ourselves. As the scale of your JavaScript projects increases, it becomes more important to self-impose some of the discipline that isn\u2019t enforced by the language.<\/p>\n
\n