Closed paul-barry-kenzan closed 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
I suppose if the interface changed, TypeScript compiler would blow up anyway. Maybe it was more of a POC "feel good" spec, lol
😏 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?
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?
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!
The first spec for the Posts Service seems to simply verify that the
post
object is set properly.