Preserving original prototype method behavior versus partial mock generation in Jasmine 4 migration

Short answer

There is no intermittent this-binding bug in spyOn(Cls.prototype, 'method') in Jasmine 4. Without and.callThrough(), the spy is a stub — the original body never runs, so there is no original-method this to get wrong. With and.callThrough(), Jasmine invokes the original function with the same this the call site supplied, so instance.method() sees the instance. That behavior is stable and not configuration-dependent. If your migration shows flaky binding, the cause is almost certainly in the tests, not the spy.

Answering your three questions

1. Does spyOn(obj.prototype, 'method') bind the instance correctly without callThrough()?

The question contains a hidden assumption. A bare spy replaces the prototype method with a stub that returns undefined (or a configured value). The original implementation is never invoked, so its this-binding is irrelevant. If your migrated tests expect the real method body to execute and observe instance state, they were relying on Jasmine 2.x-era passthrough patterns and will now fail deterministically — not intermittently. The fix is to add and.callThrough() explicitly.

2. Does callThrough() stabilize this-binding, and what are the side effects?

Yes — with and.callThrough() the original function receives the call's actual this, so prototype methods work as expected on instances. The side effects are the real ones to manage: the genuine implementation runs, touching real dependencies, timers, or network; return values come from the original unless you override them; and chaining and.stub() afterwards disables the passthrough. Treat callThrough as "partial integration test," not a free default.

3. Can createSpyObj mock prototype methods in Jasmine 4?

createSpyObj('MyClass', ['method']) builds a plain object with flat spy properties. It never reads a prototype, so it does not throw on non-enumerable properties — that failure mode belongs to spying on existing class instances whose methods live on the prototype. But createSpyObj also cannot reproduce a prototype chain, so code that calls inherited methods or checks instanceof will break against it. For class-based partial mocks, the reliable pattern is spyOn(MyClass.prototype, 'method') before instantiation, then construct real instances.

The likely source of your "intermittent" failures

Arrow-function class fields and methods reassigned in constructors are own properties of each instance, not prototype methods. A prototype spy never intercepts them — the instance's own copy shadows it. This produces exactly the symptom you describe: some tests (calling through the prototype) behave, others (calling an own-property arrow function) silently bypass the spy. Audit failing specs for method = () => {...} class fields or constructor assignments like this.method = this.method.bind(this).

Verification

class Service {
  constructor() { this.state = 'real'; }
  fetch() { return this.state; }
}

it('callThrough preserves instance context', () => {
  spyOn(Service.prototype, 'fetch').and.callThrough();
  expect(new Service().fetch()).toBe('real');
});

it('bare spy stubs the method', () => {
  spyOn(Service.prototype, 'fetch');
  expect(new Service().fetch()).toBeUndefined();
});

Run this pinned to your exact Jasmine 4 minor version and compare against the 3.x run to separate genuine version regressions from test-authoring issues. Edge cases — getters, async methods, Symbol-keyed methods — are version-sensitive; confirm against the release notes for your minor version.