My app makes calls to Expo SQLite for data persistence.
I have good unit test coverage for my business logic.
I want tests to make sure my calls to the Expo SQLite API as well as my SQL queries are functioning correctly in edge cases.
I've considered:
Snapshot testing seems to be very coupled to logic inside React components. And don't have access to ExpoSDK APIs.
E2E testing with Appium and Selenium seem more focused on how the UI looks.
I could make mocks for ExpoSDK modules, but this involves a lot of effort and potential maintenance that is sort of tangential to testing. Also this approach causes coupling the the implementation of my classes instead of to the result/business rules.
I'm imagining a testing framework that will run my tests on a mobile simulator, and make a React Native View that displays the test results. Similar to what Mocha does in the browser. Is anyone aware of such a testing framework for React Native?
Related
I recently tried TDD methodology and i really liked it. You can write some tests for specified unit, imitate different behavior, data and mock object that allows you to check only small piece of code without need of running entire application. But I have some questions about unit visualization.
Suppose we have a simple chat application with homepage, lobby and chat widget components (p. 1).
When you are working on chat widget component (for example), you can write unit test for it and don't care about other components. But what if want to see widget render results? It is so annoying to run entire application, go to lobby page, switch to chat widget tab every time I changed my code.
Are there are any practices to run render unit tests? Does it depend on technology stack?
My frontend stack: React, Redux, Jest + React testing library.
If a test shows you rendered content, than it is not a unit test. The result of a unit test must be binary (failure or success). If you have to look at test output to figure out if it was successful, it is not a unit test.
What you are looking for it not unit tests but UI test. For the Web context selenium comes to mind. It is used the define scenarios for poking at your UI and asserting on outcomes. You can also use it to automate the process of
"run entire application, go to lobby page, switch to chat widget tab every time I changed my code".
I am building a full-stack app with React and Express and I want to ask you something. I decided to improve the app I want to do a test. And what library should I use? I heard about jest or something like that to test React Component but maybe exist a modern solution. To test in express Mocha will be good or again any modern solution exist?
Testing React
There's a bunch of example Testing Recipes for testing rendering, data fetching, events and much more using Jest.
Testing Express.js
I generally recommend Mocha for most of JS unit testing, incl. Express' routes and expected results. Have a look at Express' own Mocha test set for examples.
What to test?
Well, you should test as many methods as you can. Critical methods first. Test them for returning what they should, and not returning what they shouldn't. Also test how they behave given extreme values, undefined values, etc. Check if they throw the right errors when needed.
When using authentication, ALWAYS test your routes to throw appropriate errors (like 401 or 403) for unauthorised access or insufficient privileges respectively.
If not sure what to test, spend some more time reading about testing strategies :-)
I watched Google's conference on SEO and they suggested to use Dynamic Rendering for JS built applications (React, Vue, etc). One of the tools to achieve this is with Puppeteer JS.
I need to create an app that relies heavily on SEO so Server Side Rendering (SSR) is extremely important.
I know that Next JS by default accomplishes SSR, but can I do the same with Puppeteer + Create React App? What is the difference between Next JS and Puppeteer in terms of SSR and Dynamic Rendering, and which one is better for SSR?
In short,
Next.js is a node framework. You use it to write code, i.e. build your application.
Pupetteer can be considered a tool. It comes bundles with Chromium which is practically a browsers equivalent to a testing environment. You writes tests via pupetteer to run scenarios in chromium.
I've provided an over-simplified explanation for those who want it. Shmotam gave a brilliant answer if you want depth.
Difference Between Nextjs and Puppeteer JS is very very simple.
Next Js :- It is React Framework for server side rendering those help in SEO, Optimized for Discovery , Lightning Fast Delivery.so ,very simple word is SSR. For Link https://nextjs.org/#features
Puppeteer JS it is Developed by Google and this is used for End to End testing of your application like selenium.
Both are completely Different and purpose are also different.
Headless Chrome enables "isomorphic JS" between server and client. It's a great option if your library doesn't work on the server (Node). Example for it is lit-html which it's core feature doesn't work outside the browser.
The difference is huge in terms of features.
Next.js offers some nice features that Pupeteer doesn't.
Hot reloading client & server
Automatic code splitting
Built-in CSS support, CSS-in-JS
Fetching data and component lifecycle
and more.
Some feature of Pupeteer:
Generate screenshots and PDFs of pages.
Crawl a SPA and generate pre-rendered content (i.e. "SSR").
Automate form submission, UI testing, keyboard input, etc.
Create an up-to-date, automated testing environment. Run your tests directly in the latest version of Chrome using the latest JavaScript and browser features.
Capture a timeline trace of your site to help diagnose performance issues.
and SSR apparently...
So you can see the major difference these two tools have.
Next.js is opinionated but aims to do SSR with react and builds on that concept;
Take into account that SSR with Puperteer in relatively new whereas community adoption of next.js is already mature with nice set of examples with different tech stacks.
nextjs is the powerful framework that supports ssr (server side rendering) and seo friendly Google search engine.
The react of interpretation is that the component is called after each state change. but nextjs load component and call getInitalProps first time, so view page source you can see data loaded
Puppeteer is used to make bots which works at backend.
NextJs is used to build Full Stack Website. And may be it will soon be available for React Native to make mobile apps.
I need to test some d3 based Angular components and had thought to use Selenium IDE or Kantu, but it seems that these tools cannot record interactions with SVG elements. Are there any tools that would allow me test in this way? Or will I need to rethink the problem and use a different type of testing?
There is a tool specifically made for UI testing of angular.js pages. It's called protractor . In this, test scripts have to be written in Javascript. Protractor is for end-to-end testing.
If you are going to do unit testing , then the gold standard for unit testing angular code is Karma. Karma was created and is maintained by the core Angular team and provides many utilities that make it easy to test angular apps.
A combination of both protractor and karma can completely cover an angular app functionality.
I'm new to Sinatra and Backbone. I've done testing for Rails using Rspec and Cucumber. I'm wondering the smartest way to approach testing an application built in Sinatra and Backbone.js.
I was thinking of using Rspec to test some of the logic in Sinatra and then using Jasmine to test the Backbone portion. Then I was also going to use Cucumber to do integration testing.
Is this overkill? Could one cancel the other out and render it not useful? Could Jasmine replace Rspec altogether?
I should also mention that the Sinatra app communicates with an API exposed by a separate Rails app. Maybe there is a smart way to mock/model that data to run tests on as well.
Thanks!
I'm in a similar position, in that I use Sinatra mainly for writing data API's and now write web apps using Backbone (or whatever). Since you have a data API, I'd test the API using RSpec and Rack Test, which will probably the nicer part of your day. The rest of the week you could use any of the javascript testing frameworks (Jasmine, Sinon etc…) to test the Backbone portion, and hope to get back to using Ruby as soon as possible! ;) It's up to you whether you mock the calls to the data API, or just run them against it, I think the main factor in making that choice would be speed.
I don't think it's overkill to use both, since you have a separate API it should have it's own specs, as other clients may start connecting to it too. It's also a hell of a lot easier to spec an HTTP call than whatever else the Backbone app is doing + an HTTP call.
I don't use Cucumber personally, it seems superfluous if you have the other specs, but YMMV.