What Are My Options For Unit-Testing This Method?

Question

My Ray module:

define(['Util', 'Vector3f'], function (Util, Vector3f) {
  var Ray = {}
  Ray.o = null;
  Ray.d = null;
  Ray.depth = 0;
  Ray.mint = 0.03;
  Ray.maxt = null;
  return Ray;
});

My unit test:

describe(".moveAlong(Number t)", function(){
  it("returns a point at distance t in the direction of the ray", 
  function(){
    expect(4).toBe(null); //unimplemented unit test always fails
  });
});

Ray.o is the ray's origin. Ray.d is the ray's direction. I want Ray.moveAlong(t) to return a point q such that q = o + d*t.

My understanding of unit-testing is that if I actually include my Vector3f module in my unit-test so that I can give the Ray an origin and a direction, what I'm actually doing it integration-testing. But I'll need the add() and mulScalar() methods from my Vector3f module in order to calculate ray.d + ray.d*t in moveAlong(t).

What are my options for handling my Vector3f-dependency here? I don't see how I can reasonably stub it out, but stubbing out dependencies and testing only one method at a time is the point of unit-testing.

Answer 1

Unit-testing options:

First option:
Just pass in Vector3f objects for Ray.o, Ray.d

Pros:
- Easy.

Cons:
- Preserves dependency in tests.
- Updates to components not under this test (Vector3f) may require updates to this test.

Second Option:
Create stub Vector3fs, each implementing only the add(Vector3f v), mulScalar(Number t) methods of the Vector3f module. This is super easy in Javascript, because references are typeless, and any object that has the right methods may substitute for the "right" object. Which makes me think that trying to shoe-horn OOP into this project is a bad idea, but I'm not really sure how else to approach this and that's a topic for another question.

Pros:
- Breaks dependency between Ray and Vector3f in testing code, so that further changes to Vector3f will not result in Ray failing unit tests, which cuts down on the number of failed tests to be inspected if something breaks Vector3f.

Cons:
- More code in tests.
- If Vector3f is altered in a way that lets it pass all its unit tests, but breaks functionality of Ray, then we will not see it in the Ray unit tests, either, because the dependency on Vector3f has been broken.

I'm not sure that last con is a problem - if Vector3f is passing all its unit tests, then it is obeying its contract with the other components of the system, so we shouldn't ever see a situation where Vector3f's tests all pass but it causes other components break. Further, that's an integration-level issue, not a unit-level issue.

I think the second option is the way to go.