|
Using Visual Studio, C#, Razor forms, nothing complicated, just POSTING and GETTING and updating form elements.
|
Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting with just jUnit. Given the availability of web driver libraries, you can do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were wired up correctly. I tested the actual API to make sure the system worked correctly.
In you can see an example of re-using a test that drove the API creation to check the same result from the GUI by injecting a different adapter to talk with the system under test.
- George
toggle quoted message
Show quoted text
Alan Baljeu
alanbaljeu@...
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
Test the changes to the model, not the GUI itself.
On Fri, Jan 3, 2020, 00:26 George Dinwiddie < lists@...> wrote: Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting
with just jUnit. Given the availability of web driver libraries, you can
do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were
wired up correctly. I tested the actual API to make sure the system
worked correctly.
In
you can see an example of re-using a test that drove the API creation to
check the same result from the GUI by injecting a different adapter to
talk with the system under test.
? - George
> Alan Baljeu
> alanbaljeu@...
>
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach
? ----------------------------------------------------------------------
|
That was my original motivation in building HttpUnit¡ but it¡¯s limited JavaScript capabilities don¡¯t support many of today¡¯s complex sites.?
Other than that, the Document-View pattern is your friend.?
----------------- Author,?Getting Started with Apache Maven <> Author, HttpUnit <> and SimpleStub <>
Now blogging at <>
Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
toggle quoted message
Show quoted text
On Jan 2, 2020, at 6:58 PM, Avi Kessner < akessner@...> wrote:
Test the changes to the model, not the GUI itself. On Fri, Jan 3, 2020, 00:26 George Dinwiddie < lists@...> wrote: Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting?
with just jUnit. Given the availability of web driver libraries, you can?
do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were?
wired up correctly. I tested the actual API to make sure the system?
worked correctly.
In?
?
you can see an example of re-using a test that drove the API creation to?
check the same result from the GUI by injecting a different adapter to?
talk with the system under test.
??- George
> Alan Baljeu
>?alanbaljeu@...
>?
>?
--?
??----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ??
? ?Software Development? ? ? ? ? ? ? ? ? ??
? ?Consultant and Coach
??----------------------------------------------------------------------
|
The pattern I have is
User inputs a value Form posts value to server Server responds with new model data. Form reconfigures.
"Test changes to the model" then I think means testing the web service.? So don't test the view?
On Thursday, January 2, 2020, 06:58:20 p.m. EST, Avi Kessner <akessner@...> wrote:
Test the changes to the model, not the GUI itself.
On Fri, Jan 3, 2020, 00:26 George Dinwiddie < lists@...> wrote: Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting
with just jUnit. Given the availability of web driver libraries, you can
do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were
wired up correctly. I tested the actual API to make sure the system
worked correctly.
In
you can see an example of re-using a test that drove the API creation to
check the same result from the GUI by injecting a different adapter to
talk with the system under test.
? - George
> Alan Baljeu
> alanbaljeu@...
>
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach
? ----------------------------------------------------------------------
|
Alan,
I would test the business logic of the model/web service.
I would also have a few tests that make sure the view is wired correctly to the model/web service. Not many of these.
I might also have tests that provide model data to the view and make verifications that it handles them correctly. This can be hard.
- George
toggle quoted message
Show quoted text
On 1/2/20 8:49 PM, Alan Baljeu via Groups.Io wrote: The pattern I have is
User inputs a value
Form posts value to server
Server responds with new model data.
Form reconfigures.
"Test changes to the model" then I think means testing the web service. So don't test the view?
Alan Baljeu
alanbaljeu@...
On Thursday, January 2, 2020, 06:58:20 p.m. EST, Avi Kessner <akessner@...> wrote:
Test the changes to the model, not the GUI itself.
On Fri, Jan 3, 2020, 00:26 George Dinwiddie <lists@... <mailto:lists@...>> wrote:
Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting
with just jUnit. Given the availability of web driver libraries, you
can
do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were
wired up correctly. I tested the actual API to make sure the system
worked correctly.
In
you can see an example of re-using a test that drove the API
creation to
check the same result from the GUI by injecting a different adapter to
talk with the system under test.
? - George
> Alan Baljeu
> alanbaljeu@... <mailto:alanbaljeu@...>
>
>
--
----------------------------------------------------------------------
? ?* George Dinwiddie *
? ?Software Development
? ?Consultant and Coach
----------------------------------------------------------------------
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
I¡¯ve struggled a bit with this in 2019.? I think George is right.?
With React and with Angular, it seems that a lot of the ¡°code¡± is css and html and some declarative bits here and there. Many microtests around those things feels like ¡°testing the compiler¡± and so they¡¯re not very interesting. Mocking the back-end feels wrong too.?
So it may be good to ensure that crucial bits of the JSON request are built correctly or that lookups of urls are done, and such, but for the most part i think the logic behind needs to be tested and only rather interesting bits of the front end (decision-making functions, separated from document-model manipulation stuff).?
I have seen a lot of testing done on these UI bits, but not to good effect. It was always more like something a person done and had made it work rather than something that worked for the developers. Often the tests got in the way of refactoring instead of supporting it.
So... yeah. I don¡¯t have answers, but what George says sounds right.?
Tim
I would test the business logic of the model/web service.
I would also have a few tests that make sure the view is wired correctly
to the model/web service. Not many of these.
I might also have tests that provide model data to the view and make
verifications that it handles them correctly. This can be hard.
? - George
-- Peace, Tim
-------------------------------------
|
Whole project/webcast dedicated to TDD for web apps.
James covers many topics - mock-free TDD, evolutionary design, CI,
frontend/backend, CSS TDD, realtime multiuser app, popular frameworks,
legacy code, etc
Michal
Alan Baljeu via Groups.Io wrote:
toggle quoted message
Show quoted text
|
I would do it like this:
User inputs a value Test local model updated with value. Form posts model to server. Test server handles form model and returns expected model. Force response to the model on the GUI Test the model has been updated correctly. Assume GUI updates correctly cause you if you used framework code to alter the form. Otherwise, test your hand written html as if it was a model.
On Fri, Jan 3, 2020, 03:49 Alan Baljeu via Groups.Io <alanbaljeu= [email protected]> wrote: The pattern I have is
User inputs a value Form posts value to server Server responds with new model data. Form reconfigures.
"Test changes to the model" then I think means testing the web service.? So don't test the view?
On Thursday, January 2, 2020, 06:58:20 p.m. EST, Avi Kessner < akessner@...> wrote:
Test the changes to the model, not the GUI itself. On Fri, Jan 3, 2020, 00:26 George Dinwiddie < lists@...> wrote: Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting
with just jUnit. Given the availability of web driver libraries, you can
do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were
wired up correctly. I tested the actual API to make sure the system
worked correctly.
In
you can see an example of re-using a test that drove the API creation to
check the same result from the GUI by injecting a different adapter to
talk with the system under test.
? - George
> Alan Baljeu
> alanbaljeu@...
>
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach
? ----------------------------------------------------------------------
|
On Friday, January 3, 2020, 04:07:54 a.m. EST, Avi Kessner <akessner@...> wrote:
>User inputs a value
>Test local model updated with value.
How?? This is interactive and deviates from the normal flow of the page.
.... Test server response.? OK. ... >Force response to the model on the GUI
>Test the model has been updated correctly.
I read this as, "Test changes the model.? Gui responds.? Test the model has been updated". This doesn't make sense to me.
>Assume GUI updates correctly cause you if you used framework code to alter the form.
>Otherwise, test your hand written html as if it was a model. How do you test hand-written HTML? On Fri, Jan 3, 2020, 03:49 Alan Baljeu via Groups.Io <alanbaljeu= [email protected]> wrote: The pattern I have is
User inputs a value Form posts value to server Server responds with new model data. Form reconfigures.
"Test changes to the model" then I think means testing the web service.? So don't test the view?
On Thursday, January 2, 2020, 06:58:20 p.m. EST, Avi Kessner < akessner@...> wrote:
Test the changes to the model, not the GUI itself. On Fri, Jan 3, 2020, 00:26 George Dinwiddie < lists@...> wrote: Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting
with just jUnit. Given the availability of web driver libraries, you can
do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were
wired up correctly. I tested the actual API to make sure the system
worked correctly.
In
you can see an example of re-using a test that drove the API creation to
check the same result from the GUI by injecting a different adapter to
talk with the system under test.
? - George
> Alan Baljeu
> alanbaljeu@...
>
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach
? ----------------------------------------------------------------------
|
You need to split functions into separate categories - orthogonal concerns - not confuse/couple them by end to end flow tests.?
?
TBH a lot depends on the?kind of quality outcomes you are looking for, the complexity of your UI-side logic, and the tech skills of your team.
My guess with Blazor is that this is just standard nunit tests running against C# models.? For the most part, I'd write non-200 tests here, e.g. a stubs will cover un-happy paths, malformed responses, all classes API errors, but also things like already created.? Other concerns would be tested using functional tests, probably, rather than repeat the same coverage in multiple places.
But it depends. What is your app about?? What is its most complex piece?? Why Blazor, rather than React?? Why silo front end tests, do you have a separate API team?? What are your QA processes?
The typical set of application tests might be -
1. unit tests to cover? UI model logic, and in particular, to emulate error and fault cases?
2. API tests - if you're in a silo, you should be throwing a set of consumer tests across each API release, to ensure that your basic assumptions aren't broken - if the api code is released independently from the front end (eg a microservices architecture) you need to pin down your contract by passing the API team a set of tests to litmus check your expectations are being met (PACT is one approach that you might try, but frameworks in .net weren't very mature and tbh it's easier to roll your own approach, often)
3. UI automation - a journey test that hits each API once in an end to end flow (eg. place an order)
The Cohn test pyramid is often used to describe the above - but it is also naively misquoted and rarely deeply understood - it says *you have to test at all (composition) levels*, and so the pyramid is a reflection of a typical OO composition style (i.e. not all apps will have their tests resemble a pyramid, many apps use functional tests, and unit test only negative cases.
Doing more advanced CD, for example, requires some system design, i.e. control and observation code, or the ability to run synthetic transactions against production.? I'd rather do that first than unit test happy paths. In that situation a simple stub/mockist TDD approach doesn't cut it - but how far you go depends upon the quality outcomes you're looking to achieve in terms of deploys per developer per day.?
Kennos
3, 2020 at 01:07 AM, Avi Kessner wrote:
toggle quoted message
Show quoted text
I would do it like this:
?
User inputs a value
Test local model updated with value.
Form posts model to server.
Test server handles form model and returns expected model.
Force response to the model on the GUI
Test the model has been updated correctly.
Assume GUI updates correctly cause you if you used framework code to alter the form.
Otherwise, test your hand written html as if it was a model.
On Fri, Jan 3, 2020, 03:49 Alan Baljeu via Groups.Io <alanbaljeu= [email protected]> wrote:
The pattern I have is
?
User inputs a value
Form posts value to server
Server responds with new model data.
Form reconfigures.
?
"Test changes to the model" then I think means testing the web service.? So don't test the view?
?
?
?
On Thursday, January 2, 2020, 06:58:20 p.m. EST, Avi Kessner < akessner@...> wrote: ?
?
Test the changes to the model, not the GUI itself.
On Fri, Jan 3, 2020, 00:26 George Dinwiddie < lists@...> wrote: Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting
with just jUnit. Given the availability of web driver libraries, you can
do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were
wired up correctly. I tested the actual API to make sure the system
worked correctly.
In
you can see an example of re-using a test that drove the API creation to
check the same result from the GUI by injecting a different adapter to
talk with the system under test.
? - George
> Alan Baljeu
> alanbaljeu@...
>
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach
? ----------------------------------------------------------------------
?
?
|
Sorry I'm not convinced by all answers, specially when I see end to end tests, TDD is rapid feedback and "end to end tests" are slow.
To illustrate my feelings, I've found the following article about Cohn pyramid :
I think tests like the following for example are useless: What's the purpose of the test shouldReturnGreeting() ? What is he testing really ?? A different approach can consist in unit testing with small steps hello method (String hello(@PathVariable final String lastName)), and checking if "/hello/{lastName}" is mapped to this method.
Which one gives you the fastest feedback ? In case of test break, which one will permit you to find faster where it's broken ?
Which approach document the best what you're testing ? Look at all the tests, what if we want to show last name before first name ?
Don't you feel this kind of test are like "testing the compiler" ?
The question I try to keep in mind is **"What is my SUT"** ? In this case spring framework is not, you can test it, but in my opinion its outside of TDD scope.
+1 to George Dinwiddie answer
Hope it helps
You need to split functions into separate categories - orthogonal concerns - not confuse/couple them by end to end flow tests.?
?
TBH a lot depends on the?kind of quality outcomes you are looking for, the complexity of your UI-side logic, and the tech skills of your team.
My guess with Blazor is that this is just standard nunit tests running against C# models.? For the most part, I'd write non-200 tests here, e.g. a stubs will cover un-happy paths, malformed responses, all classes API errors, but also things like already created.? Other concerns would be tested using functional tests, probably, rather than repeat the same coverage in multiple places.
But it depends. What is your app about?? What is its most complex piece?? Why Blazor, rather than React?? Why silo front end tests, do you have a separate API team?? What are your QA processes?
The typical set of application tests might be -
1. unit tests to cover? UI model logic, and in particular, to emulate error and fault cases?
2. API tests - if you're in a silo, you should be throwing a set of consumer tests across each API release, to ensure that your basic assumptions aren't broken - if the api code is released independently from the front end (eg a microservices architecture) you need to pin down your contract by passing the API team a set of tests to litmus check your expectations are being met (PACT is one approach that you might try, but frameworks in .net weren't very mature and tbh it's easier to roll your own approach, often)
3. UI automation - a journey test that hits each API once in an end to end flow (eg. place an order)
The Cohn test pyramid is often used to describe the above - but it is also naively misquoted and rarely deeply understood - it says *you have to test at all (composition) levels*, and so the pyramid is a reflection of a typical OO composition style (i.e. not all apps will have their tests resemble a pyramid, many apps use functional tests, and unit test only negative cases.
Doing more advanced CD, for example, requires some system design, i.e. control and observation code, or the ability to run synthetic transactions against production.? I'd rather do that first than unit test happy paths. In that situation a simple stub/mockist TDD approach doesn't cut it - but how far you go depends upon the quality outcomes you're looking to achieve in terms of deploys per developer per day.?
Kennos
3, 2020 at 01:07 AM, Avi Kessner wrote:
I would do it like this:
?
User inputs a value
Test local model updated with value.
Form posts model to server.
Test server handles form model and returns expected model.
Force response to the model on the GUI
Test the model has been updated correctly.
Assume GUI updates correctly cause you if you used framework code to alter the form.
Otherwise, test your hand written html as if it was a model.
On Fri, Jan 3, 2020, 03:49 Alan Baljeu via Groups.Io <alanbaljeu= [email protected]> wrote:
The pattern I have is
?
User inputs a value
Form posts value to server
Server responds with new model data.
Form reconfigures.
?
"Test changes to the model" then I think means testing the web service.? So don't test the view?
?
?
?
On Thursday, January 2, 2020, 06:58:20 p.m. EST, Avi Kessner < akessner@...> wrote: ?
?
Test the changes to the model, not the GUI itself.
On Fri, Jan 3, 2020, 00:26 George Dinwiddie < lists@...> wrote: Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting
with just jUnit. Given the availability of web driver libraries, you can
do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were
wired up correctly. I tested the actual API to make sure the system
worked correctly.
In
you can see an example of re-using a test that drove the API creation to
check the same result from the GUI by injecting a different adapter to
talk with the system under test.
? - George
> Alan Baljeu
> alanbaljeu@...
>
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach
? ----------------------------------------------------------------------
?
?
|
And that is why UI testing in general needs to be split into tests of the business logic independently of the UI. UI testing is never going to be all that fast or easy, but whatever can be automated is much faster than ?the alternative.
----------------- Author,?Getting Started with Apache Maven <> Author, HttpUnit <> and SimpleStub <>
Now blogging at <>
Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
toggle quoted message
Show quoted text
On Jan 4, 2020, at 5:03 PM, Gregory Salvan < apieum@...> wrote:
Sorry I'm not convinced by all answers, specially when I see end to end tests, TDD is rapid feedback and "end to end tests" are slow.
To illustrate my feelings, I've found the following article about Cohn pyramid :??
I think tests like the following for example are useless:? What's the purpose of the test?shouldReturnGreeting() ? What is he testing really ?? A different approach can consist in unit testing with small steps hello method (String?hello(@PathVariable?final?String?lastName)), and checking if??"/hello/{lastName}" is mapped to this method.
Which one gives you the fastest feedback ? In case of test break, which one will permit you to find faster where it's broken ?
Which approach document the best what you're testing ? Look at all the tests, what if we want to show last name before first name ?
Don't you feel this kind of test are like "testing the compiler" ?
The question I try to keep in mind is **"What is my SUT"** ? In this case spring framework is not, you can test it, but in my opinion its outside of TDD scope.
+1 to?George Dinwiddie answer
Hope it helps
You need to split functions into separate categories - orthogonal concerns - not confuse/couple them by end to end flow tests.?
?
TBH a lot depends on the?kind of quality outcomes you are looking for, the complexity of your UI-side logic, and the tech skills of your team.
My guess with Blazor is that this is just standard nunit tests running against C# models.? For the most part, I'd write non-200 tests here, e.g. a stubs will cover un-happy paths, malformed responses, all classes API errors, but also things like already created.? Other concerns would be tested using functional tests, probably, rather than repeat the same coverage in multiple places.
But it depends. What is your app about?? What is its most complex piece?? Why Blazor, rather than React?? Why silo front end tests, do you have a separate API team?? What are your QA processes?
The typical set of application tests might be -
1. unit tests to cover? UI model logic, and in particular, to emulate error and fault cases?
2. API tests - if you're in a silo, you should be throwing a set of consumer tests across each API release, to ensure that your basic assumptions aren't broken - if the api code is released independently from the front end (eg a microservices architecture) you need to pin down your contract by passing the API team a set of tests to litmus check your expectations are being met (PACT is one approach that you might try, but frameworks in .net weren't very mature and tbh it's easier to roll your own approach, often)
3. UI automation - a journey test that hits each API once in an end to end flow (eg. place an order)
The Cohn test pyramid is often used to describe the above - but it is also naively misquoted and rarely deeply understood - it says *you have to test at all (composition) levels*, and so the pyramid is a reflection of a typical OO composition style (i.e. not all apps will have their tests resemble a pyramid, many apps use functional tests, and unit test only negative cases.
Doing more advanced CD, for example, requires some system design, i.e. control and observation code, or the ability to run synthetic transactions against production.? I'd rather do that first than unit test happy paths. In that situation a simple stub/mockist TDD approach doesn't cut it - but how far you go depends upon the quality outcomes you're looking to achieve in terms of deploys per developer per day.?
Kennos
3, 2020 at 01:07 AM, Avi Kessner wrote:
I would do it like this: ? User inputs a value Test local model updated with value. Form posts model to server. Test server handles form model and returns expected model. Force response to the model on the GUI Test the model has been updated correctly. Assume GUI updates correctly cause you if you used framework code to alter the form. Otherwise, test your hand written html as if it was a model. On Fri, Jan 3, 2020, 03:49 Alan Baljeu via Groups.Io <alanbaljeu= [email protected]> wrote: The pattern I have is ? User inputs a value Form posts value to server Server responds with new model data. Form reconfigures. ? "Test changes to the model" then I think means testing the web service.? So don't test the view? ? ? ? On Thursday, January 2, 2020, 06:58:20 p.m. EST, Avi Kessner < akessner@...> wrote: ? ? Test the changes to the model, not the GUI itself. On Fri, Jan 3, 2020, 00:26 George Dinwiddie < lists@...> wrote: Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting?
with just jUnit. Given the availability of web driver libraries, you can?
do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were?
wired up correctly. I tested the actual API to make sure the system?
worked correctly.
In?
?
you can see an example of re-using a test that drove the API creation to?
check the same result from the GUI by injecting a different adapter to?
talk with the system under test.
??- George
> Alan Baljeu
>?alanbaljeu@...
>?
>?
--?
??----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ??
? ?Software Development? ? ? ? ? ? ? ? ? ??
? ?Consultant and Coach
??----------------------------------------------------------------------
?
?
|
Can you provide a concrete example of what you are asking about? Talking about GUI , form and model in the abstract can be confusing.
Basically, your GUI should be interacting with some object which I have been calling the model. Your form submission code should be reading from that object and sending the request. You can write normal TDD tests on the functions which change that object. You can assume without unit tests that when the model changes, the GUI changes correctly as well. Test that fact with something like cucumber, or puppeteer, or just do it manually.
Make unit tests that change the model as if the server returned data. You don't need an actual server for this.
On the server side, there should be some objects which don't "know about" http. Test those apis without making actual http calls.
As for testing hand written html, use a things like "getElementByID"
On Fri, Jan 3, 2020, 17:57 Alan Baljeu via Groups.Io <alanbaljeu= [email protected]> wrote: On Friday, January 3, 2020, 04:07:54 a.m. EST, Avi Kessner <akessner@...> wrote:
>User inputs a value
>Test local model updated with value.
How?? This is interactive and deviates from the normal flow of the page.
.... Test server response.? OK. ... >Force response to the model on the GUI
>Test the model has been updated correctly.
I read this as, "Test changes the model.? Gui responds.? Test the model has been updated". This doesn't make sense to me.
>Assume GUI updates correctly cause you if you used framework code to alter the form.
>Otherwise, test your hand written html as if it was a model. How do you test hand-written HTML? On Fri, Jan 3, 2020, 03:49 Alan Baljeu via Groups.Io <alanbaljeu= [email protected]> wrote: The pattern I have is
User inputs a value Form posts value to server Server responds with new model data. Form reconfigures.
"Test changes to the model" then I think means testing the web service.? So don't test the view?
On Thursday, January 2, 2020, 06:58:20 p.m. EST, Avi Kessner < akessner@...> wrote:
Test the changes to the model, not the GUI itself. On Fri, Jan 3, 2020, 00:26 George Dinwiddie < lists@...> wrote: Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting
with just jUnit. Given the availability of web driver libraries, you can
do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were
wired up correctly. I tested the actual API to make sure the system
worked correctly.
In
you can see an example of re-using a test that drove the API creation to
check the same result from the GUI by injecting a different adapter to
talk with the system under test.
? - George
> Alan Baljeu
> alanbaljeu@...
>
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach
? ----------------------------------------------------------------------
|
I insisted on "what" because it's not so obvious as it seems.
I was doing web pages before all these frameworks show up (omg I feel old), so in my old time :-) we were taught that web pages have 3 concerns: structure and semantic with html, style with css, and behaviour with javascript. So if you stay focus on what is your sut: 1 - Structure and semantic of content can you test semantic and structure ? -> yes can these tests help you to design your content structure and semantic? -> why not ?
Content is not necessarily coupled to structure but I think it's ok to bind it, some examples: Imagine you write a blog article on TDD, you collect all the questions you find on forums with the keywords: emergent design, TDD, BDD, refactoring... (or you simply talk with beginners... whatever)
You regroup these questions and priorize them, and you organize your article within this priority. It is quite similar to writing software, your readers have needs and you provide a set of features (contents) that try to respond to their needs.
In this context it may have sense to drive the wrtting of your content with tests.
Concretly, if your subject is TDD, you'll merely have a big title h1 which contains the keyword "TDD", you also may have one h2 title with the keyword "red", one with "green" and one with "refactor" or you may have a h2 title with the 3 keywords "red", "green", "refactor", followed by 3 paragraphs with a h3 title with one of these keywords....
Also because of seo and accessibility it's interesting to bind the content to structure and semantic. Seo provides some tools to measure if your content is relevant like counting words, givinfg more importance to titles, links...
2 - style with css can you test style ? -> yes can these tests help you to design your page style ? -> why not ? I'm not graphist and can't precisely answer on the utility of these tests but this is some leads that may help. The style provide infomation to the user about what he can do, this is what I would test.
for example when a user fly over a button, the button background color can enlight to 20% to alert him an action is possible, otherwise if action is blocked the background color may dim by 50% There's intrinsically some rules in web pages like "underlined text is reserved to link", "h1 title font size is bigger than h2 size"... I imagine a graphist use more complex rules, and TDD can help.
3 - behaviour with javascript Some have said you test user input, in this context of frontend it may not be totally exact.
In a javascript script the input is the webpage, you respond to event of the webpage not just user, for ex. user is writing in an input field, in the point of view of js, this is the input field which is emitting "change" event. You can have push events form the server... it's not restricted to user input.
A priori you have to test events, and idk if it can really lead your design in all cases.
To conclude (and show I'm not so old than it seems :-)), we can take the example of a web component like if it's a small web page with the 3 concerns. Our web component is a shortened description, about structure and semantic concern I would test if it contains a "summary" and "details", about style we can test if details are hidden in normal state and visible in expanded state, in behaviour we can test if when we click on summary the normal/expanded state is switching.
<shorteneddesc><summary>being conscious of what you're testing is fundamental</summary><details>you can loose yourself in useless details if it's not clear in your mind ;-)</details></shorteneddesc>
wish you the best for this new year, regards, ³Ò°ù¨¦²µ´Ç°ù²â
Le?dim. 5 janv. 2020 ¨¤?03:09, Russell Gold < russ@...> a ¨¦crit?: And that is why UI testing in general needs to be split into tests of the business logic independently of the UI. UI testing is never going to be all that fast or easy, but whatever can be automated is much faster than ?the alternative.
----------------- Author,?Getting Started with Apache Maven <> Author, HttpUnit <> and SimpleStub <>
Now blogging at <>
Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
On Jan 4, 2020, at 5:03 PM, Gregory Salvan < apieum@...> wrote:
Sorry I'm not convinced by all answers, specially when I see end to end tests, TDD is rapid feedback and "end to end tests" are slow.
To illustrate my feelings, I've found the following article about Cohn pyramid :??
I think tests like the following for example are useless:? What's the purpose of the test?shouldReturnGreeting() ? What is he testing really ?? A different approach can consist in unit testing with small steps hello method (String?hello(@PathVariable?final?String?lastName)), and checking if??"/hello/{lastName}" is mapped to this method.
Which one gives you the fastest feedback ? In case of test break, which one will permit you to find faster where it's broken ?
Which approach document the best what you're testing ? Look at all the tests, what if we want to show last name before first name ?
Don't you feel this kind of test are like "testing the compiler" ?
The question I try to keep in mind is **"What is my SUT"** ? In this case spring framework is not, you can test it, but in my opinion its outside of TDD scope.
+1 to?George Dinwiddie answer
Hope it helps
You need to split functions into separate categories - orthogonal concerns - not confuse/couple them by end to end flow tests.?
?
TBH a lot depends on the?kind of quality outcomes you are looking for, the complexity of your UI-side logic, and the tech skills of your team.
My guess with Blazor is that this is just standard nunit tests running against C# models.? For the most part, I'd write non-200 tests here, e.g. a stubs will cover un-happy paths, malformed responses, all classes API errors, but also things like already created.? Other concerns would be tested using functional tests, probably, rather than repeat the same coverage in multiple places.
But it depends. What is your app about?? What is its most complex piece?? Why Blazor, rather than React?? Why silo front end tests, do you have a separate API team?? What are your QA processes?
The typical set of application tests might be -
1. unit tests to cover? UI model logic, and in particular, to emulate error and fault cases?
2. API tests - if you're in a silo, you should be throwing a set of consumer tests across each API release, to ensure that your basic assumptions aren't broken - if the api code is released independently from the front end (eg a microservices architecture) you need to pin down your contract by passing the API team a set of tests to litmus check your expectations are being met (PACT is one approach that you might try, but frameworks in .net weren't very mature and tbh it's easier to roll your own approach, often)
3. UI automation - a journey test that hits each API once in an end to end flow (eg. place an order)
The Cohn test pyramid is often used to describe the above - but it is also naively misquoted and rarely deeply understood - it says *you have to test at all (composition) levels*, and so the pyramid is a reflection of a typical OO composition style (i.e. not all apps will have their tests resemble a pyramid, many apps use functional tests, and unit test only negative cases.
Doing more advanced CD, for example, requires some system design, i.e. control and observation code, or the ability to run synthetic transactions against production.? I'd rather do that first than unit test happy paths. In that situation a simple stub/mockist TDD approach doesn't cut it - but how far you go depends upon the quality outcomes you're looking to achieve in terms of deploys per developer per day.?
Kennos
3, 2020 at 01:07 AM, Avi Kessner wrote:
I would do it like this: ? User inputs a value Test local model updated with value. Form posts model to server. Test server handles form model and returns expected model. Force response to the model on the GUI Test the model has been updated correctly. Assume GUI updates correctly cause you if you used framework code to alter the form. Otherwise, test your hand written html as if it was a model. On Fri, Jan 3, 2020, 03:49 Alan Baljeu via Groups.Io <alanbaljeu= [email protected]> wrote: The pattern I have is ? User inputs a value Form posts value to server Server responds with new model data. Form reconfigures. ? "Test changes to the model" then I think means testing the web service.? So don't test the view? ? ? ? On Thursday, January 2, 2020, 06:58:20 p.m. EST, Avi Kessner < akessner@...> wrote: ? ? Test the changes to the model, not the GUI itself. On Fri, Jan 3, 2020, 00:26 George Dinwiddie < lists@...> wrote: Alan,
Way back, I played with test-driving AWT and Java Swing UIs, starting?
with just jUnit. Given the availability of web driver libraries, you can?
do similar things much more easily.
In general, I tested the GUI with a test API to make sure things were?
wired up correctly. I tested the actual API to make sure the system?
worked correctly.
In?
?
you can see an example of re-using a test that drove the API creation to?
check the same result from the GUI by injecting a different adapter to?
talk with the system under test.
??- George
> Alan Baljeu
>?alanbaljeu@...
>?
>?
--?
??----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ??
? ?Software Development? ? ? ? ? ? ? ? ? ??
? ?Consultant and Coach
??----------------------------------------------------------------------
?
?
|
I've done a few projects with React + Redux
(and now switching to Context / Hooks).
A component--the HTML--is declarative, as Tim suggests. The best rule
is, no logic in components--the only things allowed are wiring to
actions and pulling from injected properties. Those behaviors go into
actions / reducers, which are easily test-driven. Reducers essentially
represent global state management; actions can involve interactions with
3rd-party services.
Some folks try the Enzyme route, which allows tests to deal with either
shallowly-or-deeply-rendered components. These tests can also include
snapshot tests, which fail on any change to rendered state and act as a
weak protection against regressions (maybe useful, until you start
almost reflexively "accepting" a change, thus missing stuff you should
be examining).
I minimize my use of Enzyme--I don't feel a compulsion to test-drive
layout and declarations.
Interactions with http services are tested in a number of different ways
through 3rd party libraries like axios-mock-adapter:
mock.onGet('/users').reply(200,?{ users:?[ {?id:?1,?name:?'Joe Blow'?} ] });
? axios.get('/users').then((response) => { /* ... prod code */ });
JavaScript is a wonky though powerful-enough little language; anyone not
unit testing the even-small bits of logic in the front end is asking
for trouble. TDD works fine here.
(Angular, BTW, is a pain in the ass, particularly for testing.)
Jeff
|
| Jeff Langr / Langr Software
Solutions, Inc.???
|
| ?+1-719-287-4335
|
|
|
|
Tim Ottinger wrote on 1/2/20 10:12 PM:
toggle quoted message
Show quoted text
I¡¯ve struggled a bit with this in 2019.? I think
George is right.?
With React and with Angular, it seems that a lot of
the ¡°code¡± is css and html and some declarative bits here and there.
Many microtests around those things feels like ¡°testing the compiler¡±
and so they¡¯re not very interesting. Mocking the back-end feels wrong
too.?
So it may be good to ensure that crucial bits of the
JSON request are built correctly or that lookups of urls are done, and
such, but for the most part i think the logic behind needs to be tested
and only rather interesting bits of the front end (decision-making
functions, separated from document-model manipulation stuff).?
I have seen a lot of testing done on these UI bits,
but not to good effect. It was always more like something a person done
and had made it work rather than something that worked for the
developers. Often the tests got in the way of refactoring instead of
supporting it.
So... yeah. I don¡¯t have answers, but what George says
sounds right.?
Tim
I
would test the business logic of the model/web service.
I would also have a few tests that make sure the view is wired correctly
to the model/web service. Not many of these.
I might also have tests that provide model data to the view and make
verifications that it handles them correctly. This can be hard.
? - George
Peace, Tim
-------------------------------------
|
Gregory Salvan