开云体育

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

Le?sam. 4 janv. 2020 à?12:57, Ken Mccormack <kenmccormack@...> a écrit?:

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?

?

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@...> 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
??----------------------------------------------------------------------

?

?