thegreenhouseio / angular-webapp-seed

Angular (2+) and Webpack Seed Project for webapp projects in The Greenhouse
https://www.thegreenhouse.io/
4 stars 2 forks source link

Posts Service spec seems unnecessary #50

Closed paul-barry-kenzan closed 7 years ago

paul-barry-kenzan commented 7 years ago

The first spec for the Posts Service seems to simply verify that the post object is set properly.

it('should test PostInterface', () => {
    let post: PostInterface = {
      id: 1,
      title: 'Post 1 Title',
      summary: 'Post 1 Summary',
      createdTime: 1472091258
    };

    expect(post.id).toBe(1); // <-- is this the same `post` as the one created above? If so, this will always pass. 
    expect(post.title).toBe('Post 1 Title');
    expect(post.summary).toBe('Post 1 Summary');
    expect(post.createdTime).toBe(1472091258);
  });
ghost commented 7 years ago

it's technically testing the interface, so I guess my rationale behind that was to make sure the interface was pulled in and didn't blow anything up.

Maybe testing an interface is superfluous if it ends up getting used later on in the the test? I noticed that someone else did something similar though... ;) https://github.com/paul-barry-kenzan/karma-typescript-example/blob/master/src/example.spec.ts

ghost commented 7 years ago

I suppose if the interface changed, TypeScript compiler would blow up anyway. Maybe it was more of a POC "feel good" spec, lol

paul-barry-kenzan commented 7 years ago

😏 Ahh, gotcha. I forgot about interfaces and their ability to validate values. Maybe to increase the good feeling, a "should NOT equal" or a "should blow up" expect would indicate that the interface is doing it's thing?

paul-barry-kenzan commented 7 years ago

Would it make sense to have interface specs on their own? Haven't worked with interfaces too much in the past (and certainly haven't tested any). From an OO perspective, is it worth having those tested?

ghost commented 7 years ago

Maybe this is an example where this is more of test that the interface as a concept works, which I guess then is more about testing TypeScript, which seems out of bounds for unit testing. The PostInterface is used later on in the spec, so maybe that should suffice?

And thus this could be removed.

Personally, unless it gets unruly, I have liked keeping the interface with the corresponding class (if applicable) since generally the class will want to use that interface internally, and consumers of the class will also probably want to import the interface, so having multiple files may become cumbersome.

Thoughts?

edit: oops, you said the specs in their own file. nm!