type narrowing for common testing patterns

[rkirov]

When using 'strictNullChecks' with common testing libraries (jasmine, chai), one cannot easily express the intent that below a expect(result).toNotBeNull(); statement the object is non-null. The only solution that comes to mind is pervasive use of type assertion operator (!). Consider:

interface I {
  a: string;
  b: string;
  c: string;
}

declare function fnToTest(i: string): I|null;

function test() {
  let result: I|null = fnToTest('input');
  expect(result).toNotBeNull();
  expect(result!.a).toBe('foo');
  expect(result!.b).toBe('bar');
  expect(result!.c).toBe('buz');
}

I attempted to model the type of expect and toNotBeNull as:

interface Tos<T> {
  toBe(exp: T): void;
  toNotBeNull(): never;  // if T is null
  toNotBeNull(): void;   // if T is not null
}

declare function expect<T>(t: T): Tos<T>;

But I can't tell the type system to use a different function overload based on type of the type variable T (left in comments). Even if that was possible, I am also not sure if narrowing would propagate based on the never type.

[RyanCavanaugh]

Open to ideas on what would be possible. One suggested workaround would be to write:

  expect(result).toNotBeNull();
  result = result!;
  expect(result.a).toBe('foo');
  expect(result.b).toBe('bar');
  expect(result.c).toBe('buz');

or even just

let result = fnToTest('input')!;

In test code like this where you're explicitly asserting the postconditions and depending on an external library to provide control flow, there's not a lot of value to be gained having the types be 100% accurate when 99% will do the job better.

[dead-claudia]

Partial (albeit broader) dupe of #8655.

[RyanCavanaugh]

We've added assertion functions now and I don't think we'd go further without more feedback specific to patterns like this that indirect control flow away from the tested vlaues.