I'm using create-react-app to build my app. Do I need to do any custom testing or is it all handled by create-react-app?
Also, do the errors and prompts I receive in my terminal and console cover all testing or is there something else I need to do before releasing an app for production.
Thanks
I'm not exactly sure what you mean by testing…
If you mean unit tests, then no. create-react-app can't automatically test your application for you. It has no idea what you're trying to acomplish with your application, so it can't test it.
Or are you talking about build warnings and errors? In that case create-react-app will tell you what it is able to gather, which should be quite a bit, but it can't find possible runtime errors.
In any case if you want your whole applications functionality covered by tests, you need to write those yourself. If you're not familiar with testing in general you may want to have a look at one or more react unit testing articles (https://felixgerschau.com/unit-testing-react-introduction/ could be starting point) and depending on what you want looking into e2e tests could also be worthwhile.
Related
We have used React JS for front end and we need to write end to end tests. After researching online, we came across 2 options :
1. Selenium WebDriver
2. React Test Utils (https://reactjs.org/docs/test-utils.html)
What I understood was that with React Test Utils you can simulate clicks and check the status of the HTML elements by using methods like findRenderedDOMComponentWithXXX and that you can run these tests from command line so they will be faster.
Selenium does the same thing but from within the browser, it will allow you to write test in Behavior Driven Development Style(making it more readable)
My confusion :
Can we use React Test Utils to test a complete web page (complex component) or it is better to only test simple custom made components.
For example: If we have a component like Tasks which allows you to
add tasks, remove tasks, change priority which uses components like Input, DropDown and Toggle.
So is it a good idea to use React Test Utils for the entire Tasks component or we should use it for smaller inidividual components like Input, DropDown, Toggle
To test the complete Tasks component write end to end tests using Selenium.
Some other points :
simulate method in React Test Utils requires to pass event data which can increase small amount of work.
It will be great if some one can help me understand the difference between two.
You can use Jest and Selenium together. Don’t limit yourself to just one. You probably will go even beyond those two when you do Test Driven Development, or even Behavior Driven Development, based on what specifically you need to test. Jest by itself can’t really simulate UAT in my opinion. You need to open the browser to fully simulate the user experience, but those browser tests could be a very small percentage of tests relative to all of your tests. The reason why so many people have moved away from selenium is the bulkyness of configuration and maintenance of it. Also speed and reliability.
There are newer tools coming to life for browser based testing in recent years:
Puppeteer
https://github.com/GoogleChrome/puppeteer
Nightwatch.js
http://nightwatchjs.org
Also, your specific programming language offers additional features and enhancements to testing. Many Java developers use Maven and TestNG with their testing to build and debug their tests. Ruby developers might use RSpec. Whatever test runner you use, it might incorporate several dependencies on the backend for all kinds of testing tools for linting, html proofing, functionality, DevSecOps, database migrations, or even spellcheck. The key is to group all the tests you think you will need together in a single test runner (preferably, or as few as possible). Then run them all, back to back in a CI/CD pipeline; like Jenkins prior to deployment of changes. If any one fails, then your build fails in real time.
If you want to run several API tests in the pipeline, Newman is looking pretty decent to incorporate Postman tests you may already have laying around into a CI/CD pipeline. Of course alternatively, you could also build http clients, but not everyone has a coding skill set, so the tools you pick first should compliment the skillsets you have available to you as well.
Smart Bear also has several tools now that will run in a CI/CD pipeline for SOAP and UI testing, but those are much more expensive than the open source alternatives.
Create react app is an awesome way to setup a new react project. However i can see it forces certain decisions onto you that come baked in, eg using Jest rather than other test runners such as karma/mocha. As I am setting up a new greenfield project with React, am trying to identify is the best practise to stay with it and accept certain constraints or do most teams end up ejecting and in the parlance of brexit "take back control" and what the reasoning is.
create-react-app actually has a lot of sensible defaults and make it an ideal starting point. But they also regularly update things to stay in sync with where the industry is going. So that's great. And it is maintained by some of the same people responsible for React.
The biggest drawback (and strength) is that it doesn't include many other libraries. You have to add those yourself.
But if you do that you occasionally find that you need to add or tweak a small thing in the Babel/Webpack config.
Luckily there is a middle group. Using libraries like react-app-rewired (https://github.com/timarney/react-app-rewired) allows you to make small changes to the Webpack config without ejecting just yet.
Once you do that you will want to be very careful with upgrading react-scripts. Because every time you do it might break your Webpack changes to their script.
But only once that pain is too much would I consider ejecting.
I'm trying to decide if I should use Angular CLI for a new project. My primary reason for doing so would be to avoid the hassles of setting up a new project right now and instead focus on learning the new Angular and building the application.
I'm coming from Angular 1.x so the hassles for me stem from learning all the new tooling in addition to the new Angular. Most of the docs reference systemjs but webpack seems like the direction the community is moving in so I would like to go that route.
I would prefer to learn and become comfortable with the Angular toolchain (including webpack) but I'd like to push that off a little if possible. I generally don't prefer "black boxes" like the CLI.
I would like to start by using the CLI and then break away at a point in the future when I have time to invest in learning more about webpack, etc. My question is: What limitations does the CLI put on me, can I easily break away from it in the future, and generally what else should I consider before using it as a quick way to get started?
I started working with Angular 2 while it was in Alpha, long before Angular-cli was available. During this early stage I struggled with the build environment - I was using systemjs and a whole pile of self-built spaghetti code of gulp tasks to handle transpiling, minifying, bundling etc. For every hour I spent writing angular code, however, it seemed I was spending two hours on the build environment. Did I learn alot? Sure. Was it a good use of my time? Not very.
The angular-cli changed all of that. It was built by the Angular team to accomplish all of the development and build tasks that an angular developer needs. It is always improving and when there have been problems they have been address quickly. I now can create an ng2 project in a few minutes with "ng new projectname --style=scss." I can run immediately in development mode with "ng serve." Changes automatically get compiled. I can build for production with "ng build -prod -aot" and have my entire ng2 project ready for production in minutes with Ahead of Time (aot) pre-compilation and tree-shaking.
So my advise to anyone would be this. If you want to quickly get into the serious work of building ng2 apps, and not waste your time re-creating the build and production environments yourself, then use angular-cli.
If you have time to burn and want to learn more about what's underneath the hood with angular2, then have a go at it yourself; you will certainly gain a better understanding of things; but you'll just end up using angular-cli anyway.
I am going to argue against using the CLI.
I have been using Angular 2 from the early days before RC. Indeed there was a lot of confusion back then, having to deal with all these packaging solutions (require.js, system.js, webpack). I got to admit that it was not a pleasant time back then, and it drained a lot of time.
BUT
Nowadays, I have a strong skill set in setting up builds and deployments. I have experimented with lots of possible ways to configure it and to achieve greatness. Recently we had to develop a plugins architecture for our webapp at the office. Guess what, knowing webpack has saved my skin big time. I was able to find an initial solution which was not that great. Eventually, after polishing it and taking advantage of webpack, we have created a really nice solution, with minimal code, without interfering in either webpack or angular architecture.
There is no chance that I would have been able to do this without all the pain of having to deal with webpack constantly. I hear very often misconceptions from my peers about how webpack and angular works. I do my best to explain stuff, but nothing beats doing it yourself. I'm sorry to say, but hiding behind the CLI will do you no good. A senior developer that I can trust to create new architecture must have solid webpack, angular and typescript know-how.
If you do not understand these tools properly you will be relegated to the menial tasks of applying existing patterns never to be trusted to go out there in the wild jungle and creat the new architecture for others to follow. You need to be able to think for yourself and to take your own decisions.
Conclusion
See whether or not the CLI is the tool for your current task and choose accordingly. Don't just blindly follow the first advice you see. If you are in charge of a project and you have to call the shots, knowing webpack is a must.
I am in same situation as you, but after doing a lot of research on the subject, I have come to the conclution, that it is perfectly fine to use the CLI to build Angular 2 projects.
The CLI is supported by the Angular team and in constant development with a big community - even turorials and the NG2-Book use the CLI as the configuration.
The CLI use Webpack integrated and exposes the configuration through the CLI json, but I read that soon it is possible to use command 'ng eject' to eject the webpack config file itself (if needed).
I believe the future (even now), that it's normal to use the CLI with integrated webpack, instead of using Webpack as a seperate bundler.
I've successfully set up some tests that run complete use cases against our code base using nancy.testing.
Now I'd like to use the same tests for what we call release tests: We deploy the complete application to a staging server and run the system tests against it. We already use that approach successfully with a WCF application.
Is there an easy way to make this work? I've noticed that Browser and BrowserResponse do not use any abstractions, so I cannot replace them with a SystemTestBrowser or similar.
I could of course abstract the whole nancy.testing package away, but I thought I ask here first if someone knows a simpler approach.
Nancy.Testing does not use any network communication at all. If you can think of a nice abstract then please let us know and we can talk and see if it's something we'd like to get into the package!
One of the requested features for GAEUnit for over a year has been support for code coverage. Is it technically possible to add coverage support to GAEUnit so that after tests complete, a report could be generated of what modules were tested and what the coverage of each module was?
I can use coverage.py to launch the dev_appserver and produce a coverage report of a GAE python app but this requires local system configuration. One of the nice things about gaeunit is the ability to easily add it as an app to any python gae app so that anyone downloading the app can run the included tests. My ideal scenario would just extend gaeunit and add coverage data to the bottom of the report. So ideally the modification would run inside the dev_appserver as an app just like gaeunit does.
Is this technically possible? What approach would you recommend?
Coverage.py has a programmatic API that you can use. I don't know anything about GAEUnit, but if you need help with coverage.py, get in touch.