If I understand this correctly, you are adding an additional layer between UI and API testing (looking at the test automation pyramid)
To my understanding, automated tests on an API level (here a web request to the backend) should purely focus on whether the purchase works with differnt input coming from a potential "non-trustworthy" client. Does it really matter at this point, whether the button is broken or not for all data driven tests in this regard?
Why is this particular test (button disabled or not under the conditions given) not addressed in a pure UI test?
I think what you're saying is essentially what the ToTT is trying to convey, if you write UI you will test UI.
The inspiration for the ToTT is that many developers who write UI don't test UI components, instead they test "controller instances", especially those who come from a backend background. In Java world you test your `new Stuff()` but in UI you render it and interact with it.
There is no underlying backend, you would mock/fake out those dependencies on either strategy. Otherwise this would be e2e testing.
Another way of putting it is (based on Dave Cheney's unit testing talk), to write unit tests you must define a unit. In UI your unit is your entire component (JS + HTML template) and not just the controller (JS).
I argue that the same principle applies to native UI like Desktop or Android apps, but rendering may not be as simple as web with headless browsers, although some alternative based on the same idea exist.
1. Test the API, all values, invalid, fuzzy, auth, etc. 2. Ensure that button has the right callback assigned (to call API in #1) 3. Ensure that clicking the UI button calls the callback.
The key difference is that #3 is done through mocking, where you assert that the button called your mock. You do not involve the real API at this point.
Rationale: You already asserted that calling the API works (tested in #1). So what you need left is to test: (a) did you call the API; and (b) did you handle correctly the results of such call.
If I understand this correctly, you are adding an additional layer between UI and API testing (looking at the test automation pyramid)
ReplyDeleteTo my understanding, automated tests on an API level (here a web request to the backend) should purely focus on whether the purchase works with differnt input coming from a potential "non-trustworthy" client. Does it really matter at this point, whether the button is broken or not for all data driven tests in this regard?
Why is this particular test (button disabled or not under the conditions given) not addressed in a pure UI test?
T.
I think what you're saying is essentially what the ToTT is trying to convey, if you write UI you will test UI.
DeleteThe inspiration for the ToTT is that many developers who write UI don't test UI components, instead they test "controller instances", especially those who come from a backend background. In Java world you test your `new Stuff()` but in UI you render it and interact with it.
There is no underlying backend, you would mock/fake out those dependencies on either strategy. Otherwise this would be e2e testing.
Another way of putting it is (based on Dave Cheney's unit testing talk), to write unit tests you must define a unit. In UI your unit is your entire component (JS + HTML template) and not just the controller (JS).
I argue that the same principle applies to native UI like Desktop or Android apps, but rendering may not be as simple as web with headless browsers, although some alternative based on the same idea exist.
Hello,
ReplyDeleteI would like to understand it better, how you render your component with JS+HTML without open the browser?
You do open a headless browser, so rather than a nodejs runtime your runtime is this headless browser where rendering is possible
DeleteWhy not testing them separately a better thing?
ReplyDelete1. Test the API, all values, invalid, fuzzy, auth, etc.
2. Ensure that button has the right callback assigned (to call API in #1)
3. Ensure that clicking the UI button calls the callback.
The key difference is that #3 is done through mocking, where you assert that the button called your mock. You do not involve the real API at this point.
Rationale: You already asserted that calling the API works (tested in #1). So what you need left is to test: (a) did you call the API; and (b) did you handle correctly the results of such call.