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".
Related
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?
I am trying to write tests for one of our rich text components which was implemented with slate js editor in react js. So when writing tests, I am retrieveing the element div[contenteditable='true'], but not able to simulate events like change, blur, focus. The handlers attached to editor component are not getting called. I tried multiple combinations, but no luck. Can someone please help on this? Is it possible to simulate events for contenteditable element using testing library (contenteditable is implemented using slatejs)?
Like you've discovered, contenteditable isn't supported by JSDOM. React Testing Library (RTL) is built on top of JSDOM, so it's not possible to test the Slate editor properly with RTL until JSDOM implements support for contenteditable.
Use a browser automation library together with Testing Library
Your options are then to use a tool that creates a real browser context. Testing Library have integrations with many tools that do exactly that: TestCafe, Cypress, Nightwatch, Puppeteer.
You can also use the above tools on their own, without Testing Library.
I've solved this using Puppeteer, and there are two approaches:
Run a local server and tell Puppeteer to go to something like localhost:3000
Set the content directly with page.setContent(htmlString)
(1) is the most common, and you'll find many guides for this since it's a common approach for end-to-end testing (google search).
(2) is a little trickier because you will have to transform and bundle your source for each test, and then inject it as HTML into the browser page. I prefer this approach because the testing experience is much more similar to using RTL. I've created a repository with an example of this setup with the Slate editor here: https://github.com/marcusstenbeck/puppeteer-react-testing-template/
Hi I am developing a few SharePoint Web Parts with ReactJS and are ready to test them. Installed Mocha and Chai ok and test runs ran OK. The first two apps I am testing work as follows:
1. Search component - A jQuery Autocomplete that pulls data via the Fetch method and pushes this to the Input Div to perform searching and appends this data to some Input fields.
2. A-Z List - A Directory type application that allows users to navigate through locations from A to Z and view particular details about each location. Again data is pulled from SharePoint list via Fetch and then objectified:
(var myobj = data.map(item){return {value: item.title }} ).
They both make use of Material-UI themes (MUI) and in particular - Tabs,Tables,TextField, RaisedButton,Dialog.
I also have Interfaces as mentioned in separate classes.
Now I want to test and writing a some test and want to do tests with Describe and It methods but since this is my first time doing formal software testing I was wondering a few things and need advice:
What high level functionality should I test?
If I was to begin I am thinking of testing the following elements/components:
2a. Render method - Render()
2b. Class definitions - export default SearchCmp extends Component
2c. Main Divs - Important divs that need to be rendered.
2d. Navigation in the AZ list
2e. Fetch return - Does it equal to true?
So all in all I don't know if I am planning this right with the above areas to be included and two can you provide code sample or advice for such tests if they will be useful for me? jsdom is available too as we can't have access to real dom.
Thanks
Following this guidlines : NodeJS Testing with Chai and Code Quality. https://www.lynda.com/Node-js-tutorials/Assertion-libraries-correctness/587672/654554-4.html?srchtrk=index%3a1%0alinktypeid%3a2%0aq%3achai%0apage%3a1%0as%3arelevance%0asa%3atrue%0aproducttypeid%3a2
Once finished I should be in better position to design Unit and Integration tests.
The actual loading time of a web page and the user impression of that loading time can be quite different. For example, here are three different experiences a user can have while a page loads:
Waiting for a blank page to completely render at once
Parts of the page immediately render (e.g. top navigation) but components load
individually
The entire page is made of components that load individually
These different UI experiences become more common as JavaScript frameworks become more common, such as React or Angular.
The user's UI experience can also change if individual components use loading markers to indicate something is happening, such as Loading... or a spinning wheel.
What are some guidelines for improving the user impression of a fast loading page? If there are not any, how do you approach this problem?
There is always going to be an initial hit whilst the javascript gets parsed and executed. However, if you are after very fast initial loads you could try a few techniques such as:
Delivering a "critical" payload first which will quickly load the "essentials" of your webpage to make it feel much more responsive. Webpack has a code splitting feature that you could use for this effect.
Making use of Server Side Rendering (i.e. universal style applications) which will execute the javascript server side and embed the output in the HTML payload. This probably renders the best results for what you are after as you don't getting the "flashing" parts as much you would otherwise. It's a pretty cool technique but is probably presents more technical challenges so you will have to decide on your own tradeoffs.
If you are after an example of SSR you could look at a boilerplate I recently put together for React: https://github.com/ctrlplusb/react-universally
In that boilerplate I actually also make use of Webpack's code splitting feature based on the Routes defined within the application. Checkout webpack's docs on this: https://webpack.github.io/docs/code-splitting.html
If webpack is completely new to you I highly recommend the survive js series: https://survivejs.com/
I am writing an angular application, whereby my controller calls an API, that returns live data which I then display on my html doc.
I am using Protractor for my end to end tests, and jasmine for unit testing.
I am mocking my API call, to ensure the API is not called.
My question is whether I should be testing the API call with protractor, and check whether my html doc is updated following the GET request, or whether I should test the API call when conducting my unit tests with jasmine.
I have a feeling that the answer is that I should be testing this API call with both my unit and end to end tests, but am hoping someone on SO can provide clarity.
The main goal of unit testing is to test that your code (be it JavaScrip or otherwise) is doing what it should. Each test should be done against data that static or contrived and should never be run against an API. Static data gives you the control you need. If your code needs to branch when X equals 7, you can purposely set that value and verify that your code does indeed branch. When you run against an API you do not have that control. Even if you are the one that controls the API, doing unit testing against it is a bad habit to get into.
End to end testing is completely different. Here we are not testing that the code works on a granular level (we already did that in our unit tests) we are testing that the application works as a whole. When a specific button is clicked in the application, did the expected things happen? Do all of the expected elements appear on the page? You still need to be testing against known data, and doing that is just as crucial as in unit testing, but here you get to see how your app reacts against when running. Did a particular screen take too long to load? Did a button click not give you what you expected? This kind of testing lets you click through your application as a user would (except much faster.)
You should run both kinds of tests on your app. Unit tests should be run during the build process, and end to end tests should be run once the build completes.