5 ms·

We have hundreds of tests for our client side projects (web app, mobile app), and they definitely do more than what you describe. Some are simple (although ver

We have hundreds of tests for our client side projects (web app, mobile app), and they definitely do more than what you describe. Some are simple (although very few are as simple as your example) and some are complex, depending on the portion of the app being tested. Some are basically integration tests for components/widgets, where it runs it in isolation to test the inputs and outputs. Others are more like traditional unit tests where it's purely testing business logic, API and model interactions (mocked), form validation logic, etc. Unless you're talking about very simple client apps, there's always stuff that can be tested that will provide significant business value by preventing bugs and broken code from getting to end users

a_wild_dandan 3y ago
Could you give an example? Most UI tests I see are either a) trivial/tautological, b) test implementation details, or c) doesn’t actually even test the UI, i.e “what is visually painted on-screen.”
- latchkey 3y ago
  https://github.com/lookfirst/mui-rff/blob/master/test/Autocomplete.test.tsx https://github.com/lookfirst/mui-rff/blob/master/test/Autoco...
- gary_bernhardt 3y ago
  Almost none of the e2e tests for https://www.executeprogram.com https://www.executeprogram.com meet this description. They're all tests like: - Visit a lesson page with a code example that returns a string. - Enter the correct answer to that code example, but without the quotes around it. - Assert that the text "Almost, but the answer is a string so it needs quotes." now exists on the page. No implementation knowledge, nothing faked, real UI behavior tested. You can test most app behavior like this. E.g, we test our entire billing system like this, making these kinds of real assertions. (To make sure that we know when actual rendered pixels change unexpectedly, we use Percy, which is a separate topic.)
- pixelrevision 3y ago
  At work we use snapshot tests to see visual changes to ui. It helps a lot with code review especially with adding edge case data to tight designs. We use ui tests specifically for testing accessibility, analytics and data passed along during navigation. We use fixtures for all of this. None of these tests really help with bugs. What they do help with is: - Making sure the ui stays really decoupled from the business logic. This helps a lot with getting the data unit tested which does help a lot with bugs. - Making sure that analytics and accessibility are not forgotten about. This helps a ton when refactoring. - Making the intent of the code really clear during review. It takes a bit of practice and being ruthless about removing/fixing stuff that’s not helping. I have found it makes it much easier for new developers to work, review code and understand how the code is organized. YMMV.
- LocalPCGuy 3y ago
  We have UI client tests that cover everything from API, the business logic layer, as well as testing any local logic in higher order and UI components. Some examples: - At the API layer, it mocks the network layer and tests that, when triggered, it sends the correct request and given a response, handles it correctly (both for success and fail responses, as well as different expected data). - business logic layer is some of the most important tests, this layer will test things like how data flows through the app and how it might be transformed along the way for use in the UI. This layer generally sits between the API and UI, so it mocks functions in the API stack and tests various responses, tests streams of data. This layer often is your "traditional unit tests" - testing individual functions to ensure they are idempotent, no (unintended) side effects creep into the code, putting in X gets back Y, etc. - Higher order UI components - these are components that, while they may have some UI (yah, I know, not purely higher order), they are generally the component that acts as an intermediary between the business logic and more pure UI (display) components. The tests here would mock any calls into the business logic, make sure it properly requests the needed data and then check to see that any local logic is correct. This layer may be handling route params or query params, and adjusting the data request based on that or other data stored in memory or in the app. It may be handling collection of form data and giving it to a business logic function, and handling any errors that may send back, and the tests will check that. It often has functions that are triggered by actions in display components, and rather than try to wire components together in tests (we do have some e2e tests that check at that level), it's better to test those functions in isolation at this layer. - Display UI components - I don't want to assume, but based on the comments, this is likely what you have thought of when you think of UI testing. At this layer, there should be much less logic in each component. It usually has data inputs, and then renders that into a template. We don't "test the framework" - there's no sense testing that an input prop is "set" correctly. But if the UI component does anything with that prop to prepare it for display, we'll test that. Or if it has UI actions - this is one place we will sometimes tie to the DOM and test things like click events, but most of the time that isn't really necessary (again, we make as assumption that if we properly wire up a click handler, it will fire on click). So many times we will just test the handler themselves, if they do any logic prior to emitting that value back out to a higher order component or to the business logic layer. We try to keep these simple, but there are sometimes tests here that are testing that expected DOM elements are visible based on the state of input data, or that the expect text is visible based on user action (i.e. did a panel display text when the user clicked it open). This is the layer we have to be fairly careful not to write "lazy" tests (did the framework render the text assigned to a variable and interpolated in the template isn't super valuable). If it matters (and I don't think it should, because the practice of writing good tests, even for client apps, isn't specific to language/framework) our primary apps right now are written in Flutter and Angular. We also use or have used Swift and Kotlin (iOS/Android respectively), Java, React (little bit of React Native but quickly abandoned in favor of Flutter), and Ember (had a pretty big test suite for an Ember app, since shut down though). And, despite all of the above, most of our logic does not actually reside on the client side but rather lives in the API/backend and we are mindful to try to keep as much logic there as possible. And we have good test coverage there as well. Of course, for all our code, the coverage could always be better. Anyways, I can't really pull code samples as the apps are proprietary (and this is getting long enough as it is), but I hope that answers your question and helps illustrate at least why I believe there can be significant value in client side tests.

a_wild_dandan 3y ago

Could you give an example? Most UI tests I see are either a) trivial/tautological, b) test implementation details, or c) doesn’t actually even test the UI, i.e “what is visually painted on-screen.”

latchkey 3y ago
https://github.com/lookfirst/mui-rff/blob/master/test/Autocomplete.test.tsx https://github.com/lookfirst/mui-rff/blob/master/test/Autoco...
gary_bernhardt 3y ago
Almost none of the e2e tests for https://www.executeprogram.com https://www.executeprogram.com meet this description. They're all tests like: - Visit a lesson page with a code example that returns a string. - Enter the correct answer to that code example, but without the quotes around it. - Assert that the text "Almost, but the answer is a string so it needs quotes." now exists on the page. No implementation knowledge, nothing faked, real UI behavior tested. You can test most app behavior like this. E.g, we test our entire billing system like this, making these kinds of real assertions. (To make sure that we know when actual rendered pixels change unexpectedly, we use Percy, which is a separate topic.)
pixelrevision 3y ago
At work we use snapshot tests to see visual changes to ui. It helps a lot with code review especially with adding edge case data to tight designs. We use ui tests specifically for testing accessibility, analytics and data passed along during navigation. We use fixtures for all of this. None of these tests really help with bugs. What they do help with is: - Making sure the ui stays really decoupled from the business logic. This helps a lot with getting the data unit tested which does help a lot with bugs. - Making sure that analytics and accessibility are not forgotten about. This helps a ton when refactoring. - Making the intent of the code really clear during review. It takes a bit of practice and being ruthless about removing/fixing stuff that’s not helping. I have found it makes it much easier for new developers to work, review code and understand how the code is organized. YMMV.
LocalPCGuy 3y ago
We have UI client tests that cover everything from API, the business logic layer, as well as testing any local logic in higher order and UI components. Some examples: - At the API layer, it mocks the network layer and tests that, when triggered, it sends the correct request and given a response, handles it correctly (both for success and fail responses, as well as different expected data). - business logic layer is some of the most important tests, this layer will test things like how data flows through the app and how it might be transformed along the way for use in the UI. This layer generally sits between the API and UI, so it mocks functions in the API stack and tests various responses, tests streams of data. This layer often is your "traditional unit tests" - testing individual functions to ensure they are idempotent, no (unintended) side effects creep into the code, putting in X gets back Y, etc. - Higher order UI components - these are components that, while they may have some UI (yah, I know, not purely higher order), they are generally the component that acts as an intermediary between the business logic and more pure UI (display) components. The tests here would mock any calls into the business logic, make sure it properly requests the needed data and then check to see that any local logic is correct. This layer may be handling route params or query params, and adjusting the data request based on that or other data stored in memory or in the app. It may be handling collection of form data and giving it to a business logic function, and handling any errors that may send back, and the tests will check that. It often has functions that are triggered by actions in display components, and rather than try to wire components together in tests (we do have some e2e tests that check at that level), it's better to test those functions in isolation at this layer. - Display UI components - I don't want to assume, but based on the comments, this is likely what you have thought of when you think of UI testing. At this layer, there should be much less logic in each component. It usually has data inputs, and then renders that into a template. We don't "test the framework" - there's no sense testing that an input prop is "set" correctly. But if the UI component does anything with that prop to prepare it for display, we'll test that. Or if it has UI actions - this is one place we will sometimes tie to the DOM and test things like click events, but most of the time that isn't really necessary (again, we make as assumption that if we properly wire up a click handler, it will fire on click). So many times we will just test the handler themselves, if they do any logic prior to emitting that value back out to a higher order component or to the business logic layer. We try to keep these simple, but there are sometimes tests here that are testing that expected DOM elements are visible based on the state of input data, or that the expect text is visible based on user action (i.e. did a panel display text when the user clicked it open). This is the layer we have to be fairly careful not to write "lazy" tests (did the framework render the text assigned to a variable and interpolated in the template isn't super valuable). If it matters (and I don't think it should, because the practice of writing good tests, even for client apps, isn't specific to language/framework) our primary apps right now are written in Flutter and Angular. We also use or have used Swift and Kotlin (iOS/Android respectively), Java, React (little bit of React Native but quickly abandoned in favor of Flutter), and Ember (had a pretty big test suite for an Ember app, since shut down though). And, despite all of the above, most of our logic does not actually reside on the client side but rather lives in the API/backend and we are mindful to try to keep as much logic there as possible. And we have good test coverage there as well. Of course, for all our code, the coverage could always be better. Anyways, I can't really pull code samples as the apps are proprietary (and this is getting long enough as it is), but I hope that answers your question and helps illustrate at least why I believe there can be significant value in client side tests.