Consider to run specs over concatenated build (> noConflict)

[webpro]

Consider to run specs over concatenated build (> noConflict)

[ifandelse]

@webpro - I knew this day would come. :-) Ultimately, it seems like it's a wise move to run the specs against the concatenated build (and thus, public API). I've been testing the src files directly in order to test private behavior that wouldn't be accessible from the postal namespace. But with what we've discussed about where things are headed (custom builds, moving the fluent SubscriptionDefinition options out to an add-on that treats them like "Strategies" you can apply to a subscription, etc., then we're effectively reducing the surface area of "private code" inside the namespace and that's probably a good thing. thoughts?

[webpro]

The general consensus is indeed to unit test only the public API iirc.

But it depends on the situation, sometimes I want to (unit/perf) test specific internal things. Usually this is still possible if things are organized well in modules. But I guess it's best to see how things work out by testing only the public interface. If that's not sufficient, then I'm happy to take another look.

[ifandelse]

@webpro I'm trying to take some time today and tomorrow to look into some of this. I'd definitely like to move to public-API-only tests....will keep you posted

[ifandelse]

I'm such a dummy! :-) Apparently, I moved to testing the built output some time ago. That's what happens when your brain goes to mush from no sleep.