The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

gishu (4) [Avatar] Offline
#1
Context: We build mostly diagnostic rich client GUI apps in C# talking to a bunch of services.

In my advisory capacity, I've helped local teams to bridge the gap from mostly manual to test automation (workflow tests). We have automation layers for each project that encapsulate the GUI

Now they've hit a plateau (and it seems to me that they're going off the other edge of the lane). It seems to me, that with their new found comfort in automating, anything that can be automated is being automated at the expense of other types of testing (e.g. testing trivial GUI interactions)

Towards the end of the "tacking unreliability" section of Chap 10: Validating Frequently,
you mention separating exec specs from 'infrastructure'.

* Separate business logic from infrastructure
* Test business logic via exec specs ; 'mocking'/isolating infrastructure roles
* Test each infrastructure role with technical tests
* Add one end to end test that tests everything is wired together

The current situation is where everyone is exclusively writing end-to-end workflow tests - causing slow feedback, intermittent failures and high maintenance. Any dip in confidence strengthens the over-reliance on end-to-end tests.

Also I think bullet#1 isn't met... the underlying design has infrastructure bits seeping into the presentation layer making it difficult/a hassle to isolate.

Question: How do I influence teams to change their stance ? It's a kind of chicken and egg problem with having to influence the dev teams to define roles better, which would then enable test teams to write fast specs. Inability to write specs, causes the devs to further muddy the port between the logical pieces and the infrastructure implementations.

Thanks for reading (and great book Gojko. Keep writing...)