Can someone help me understand when I would use one vs. the other? I can’t quite figure it out from the Testing tutorial.
Thanks!
1 Like
They’re not really exclusive. You use Meteor’s full-app integration mode in order to do acceptance testing.
If you try to do acceptance testing without the full mode, Meteor will not eagerly load any app files, which means it’s up to your tests to do so. In full-app mode. This leads to faster load times.
When you do full-app Meteor will load the entire app, and for doing acceptance tests you need this.
Hope that clears it up.
Hmm… still not following you Sam.
The Testing guide illustrates two fairly different approaches. For example, full-app integration mode uses FlowRouter to navigate around while acceptance testing uses Chimp + browser.url(). That’s why I’m confused 
It can be confusing!
Can you show me where you’re looking?
1 Like
Ah, I think i see the confusion
So think of a mobile phone.
Integration testing is like opening the phone and using a multimeter to test one part of the circuit at time. Like seeing if the display module works by itself. For that, you might use engineering knowledge to get the display to show a pattern. This is like using flow router to go right to a specific route using the internals of the app.
Acceptance testing is when you use the phone as a whole. You don’t have access to the internals. So you have to use the touchscreen since you don’t have access to the internal circuits. Chimp uses the UI and sets the URL to get to different parts of the app.
Gotcha - that’s helpful. So if this were a small personal app, would you prioritize one vs. the other?
(User) acceptance tests make sure that the feature implementation delivers what the user story and defined acceptance criteria required. If you are the only user of your app, I think there is no big benefit in automating acceptance tests, because you are the only person that judges if the software is still acceptable to you.
(Full-app) integration tests make sure that your developed units work together, as they should.
Bonus: http://googletesting.blogspot.com/2015/04/just-say-no-to-more-end-to-end-tests.html
Acceptance testing is very important if you anticipate your app to be long-lived, and to migrate across multiple technologies. Integration and unit testing, on the other hand, tend to be more tied to a specific language, framework, or stack.
So, for example, I have one small app that calculates the Black & Scholes Algorithm that’s been walked through nearly 6 different languages (Excel, MatLab, SPSS, C++, C#, JavaScript). The unit tests had to be re-implemented in each language; but were necessary in confirming the algorithm’s correctness in each case. Ug.
On the other hand, we’ve been using Nightwatch since 0.6.5 days when Meteor was based on Spark, and have walked apps through the Blaze upgrade, package infrastructure upgrades, ecmascript upgrade, hosting providers, database clustering upgrades, and now to React and Angular. Nightwatch is still going strong, and we haven’t had to rewrite our tests. The downside is that it only works for browsers, and not for native apps (i.e. no Cordova, React Native, Electron, etc).
Integration testing on the other hand, lets us do things like extract packages from apps, refactor to modules, check business logic, implement a microservice architecture, etc. And has been very important in getting a release track published, which is letting us coordinate packages between different apps.
At the end of the day, it’s a question of what you want to keep stable. Do you have a clear idea of your business, your use cases, and your user interface? Are you wanting to experiment with different technology to (re)implement that app? If so, then use acceptance tests to lock down your user interface. Or do you have a clear idea of the technology you want to use? A particular kind of database, specific libraries, tools, etc? And are you more likely to be experimenting with user workflows, interfaces, and business models? If that’s the case, then go with integration testing and lock down the internals.
1 Like