Hi guys,
I’m very beginner in test. I have an application that written with Meteor+React I want know to how we can add test to it?
I want write test with one tools for both server and client side.
Facebook and React community suggest Jest but I see Mocha and Chai is mentioned in Meteor guide.
Which one is better for start?
Can you guide me a little as a good start point?
What are you wanting to keep consistent? What do you want to lock down so it doesn’t break?
Jest is best for components.
Mocha is best for business logic.
Nightwatch is best for user experience validation.
Postman is best for APIs.
Istanbul is best for code coverage.
etc.
They each do different things.
Definitely, Jest + Chai as assertion library. You can find some sample tests on server components in this repo: https://github.com/ssr-server/ssr
Jest is also incredibly productive when testing UI components. It’s snapshot capabilities is amazing.
Anybody have a good Jest/Meteor tutorial?
I kinda like Chimp as it does a lot for you. It has good meteor support, setup is really easy, and you can specify which test/assertion-library you want to use(Mocha, Jasmine, Cucumber.js, …). Do the demo on their site.
Default tests use Cucumber, which is sort of funky at first, but it quickly grows on you, and it becomes really fast to write them.
Someone told be, If you just started writing test, do end-to-end tests first, not components. And now, I agree. With Chimp it is dead-easy to get started.
So we can’t use one test framework for both client and server? right?
So based on your message I think we should first try End-to-End test (for example @awatson1978 introduce Nightwatchjs for it) and then do component test (for example with Chimp or Jest) and then unit and business test (for example with Mocha). Is it right?
When I recently started testing, unit tests seemed the way to get started, as it seemed to be the easiest to do: it’s simple and isolated. But it did not give a lot more confidence that my app was running as it should be as a whole.
E2e-test looked as it would give more confidence that your app works as it should be to a user( 'if I click on this button, I should be taken to the home-page, and I should see my logo…), but looked a lot harder to set up: setting up a program to click on actual buttons in an actual browser must be difficult.
Enter Chimp: Basically a 1-click install for all test-packages, and your good to go. I does all the setup you need for e2e, but you can use it for unit-testing as well.
One of my apps is now fully covered by e2e, and I still have to do most of the unit-test. But as a whole, I am now much more confident in releasing updates.
Try the Chimp tutorial and see if it works for you.
Not so. Mocha+Chai can run on both client and server. I’m pretty sure Jest also runs on both.
However… A user doesn’t interact with both. A user generally only experiences the client. So having a test system run on both client and server doesn’t necessarily always get you what you need. Business logic tends to run on both client and server. If you have a critical need for server side rendering, then components will render on both client and server. But the bulk of user interaction happens on the client; with the user interrogating the app as a black-box system.
Well… depends on what kind of app you have.
If there is some business logic and algorithm that has deterministic inputs and outputs, that can be a good place to start writing Mocha tests. Certainly if you have any math algorithms; or string manipulation functions, helper objects, etc… start there.
If you’re building a custom library of UI components with React that will need server-side-rendering, Jest is the bee’s knee.
If you’re building something with a REST API, then Postman can be a good place to start.
If you’re using a bunch of packages, and want to assemble them in different ways, and test that the package integrations work consistently, try Gagarin.
All that being said, most testing generally falls under user experience testing. Click this button and make sure the app does foo. For that, you need some sort of end-to-end rig like Nightwatch or Chimp.
If you have a really clear user experience - particularly one that everybody agrees upon - start with an E2E script walkthrough. The script should be able to double as a sales demo, a training tutorial, and a test script. If the script doesn’t work as sales and training, then you don’t have a user experience that the entire team agrees on. But if such a script exists, start coding it up with E2E runner.
User accounts and multi-user apps definitely deserve an E2E setup to verify the account signup/login process, which is filled with way more edge cases than people generally realize.
CRUD pattern can be a useful starting point; but designers will bellyache and want to skip to arbitrary designs.
The biggest problem with E2E is that many companies haven’t decided on the user experience. Many teams won’t have the discipline to work with a QA process. And designers and business stakeholders may be accustomed to graphic design workflows where they can constantly ‘tweak’ the user experience. And by ‘tweak’ I mean ‘introduce bugs to accommodate their idiosyncratic preferences’.
Regarding Nightwatch vs Chimp.
Nightwatch is the older of the two, and is an expert testing system. It was originally just an E2E runner written in Node; written around the same time Meteor was created. It has a sophisticated JSON config file that allows it to adapt to many environments; and allows you to walk an app from one environment to the next; and to swap out entire infrastructure layers in an app. It’s supported by the likes of Walmart, and compiles to a format supported by SauceLabs, BrowserStack, etc. I know of two applets that have been walked from PHP to Spark to Blaze to React using Nightwatch (our biometrics CRUD pattern and our D3 charting specs).
Chimp is the newer of the two, and is intended to lower the barrier to entry for teams and developers new to testing. It’s always been intended to be Meteor centric.
There are some clear cultural and gender ratio differences between the two projects. About a quarter or a third of the Nightwatch userbase are women working as professional testers in industry settings… healthcare, finance, etc. And the lead developer is Dutch, working out of the Netherlands, I believe. So Nightwatch has a rather egalitarian New York / Amsterdam / London vibe going on. If you’re uncomfortable getting help or direction from a woman at a Wall Street finance firm or a London hospital, then the Nightwatch mailing list might not be for you.