We’re excited about Meteor 1.3’s testing support. This is a link to the article explaining why.
2 Likes
Thanks for the post. Overall I’ve been happy with Meteor 1.3’s testing support, but the meteor test rebuild/re-run lag times really kill test-driven development. TDD requires the test/code change feedback loop to be almost instant. Making a test change, waiting 4-7 seconds, verifying a fail, making a code change, waiting 4-7 seconds, verifying a pass … is really quite frustrating. I know there are other options (like running your tests outside of Meteor, leveraging webpack, etc.), but I can’t wait until Meteor’s built in unit test support (and overall build times) get’s faster.
Thanks for the comment. I totally agree with you that the test/results feedback loop has to be much faster to support a TDD rhythm. TBH I don’t think it will ever be fast enough as long as it depends on the build times. Looking at this discussion to get some isolation from the build & meteor import dependencies.
Definitely - I’ve been following that discussion as well; I can’t wait to see this all get better! To be honest though the first time I looked at one of those Wallaby config files, I blacked out for about 20 minutes …
1 Like
@hwillson I still black out when I look at that wallaby config file! It’s certainly not beginner friendly.
Wallaby has some amazing caching, instrumenting and a multi-threaded building approach that makes it super fast. @Sanjo did some great work to copy the Meteor boot.js logic into Wallaby, as to get the benefits of wallaby’s multi-threadedness and caching. This is how we’re able to get near-realtime feedback from unit AND integration tests.
2 Likes
Absolutely - I really appreciate the work you and @Sanjo have put into this, so thanks! I’m really close to pulling the trigger and diving into the Wallaby integration myself. I’ll post back with my findings and anything additional I can add to the discussion.