Ash Manda (Oct 16 2026 at 16:36): Ash Manda (Oct 16 2026 at 16:36):Also fyi the tests are all named *JT.java
Ash Manda (Oct 16 2026 at 16:36):as in JSF Tests
Oliver Bertuch (Oct 16 2026 at 16:36):Yeah I noticed! Fancy fancy fancy!
Philip Durbin 🚀 (Oct 16 2026 at 16:37):Is that some sort of best practice? JT? :sweat_smile:
Ash Manda (Oct 16 2026 at 16:38):no but it lets us pattern match very quickly if we need to without tags. Frontend tests are *JT. API tests are *AT. Unit Tests are *UT. Integration Tests are *IT
Oliver Bertuch (Oct 16 2026 at 16:39):We're establishing our own best practice as outlined in :wink:
Oliver Bertuch (Oct 16 2026 at 16:46):Ash Manda said:
no but it lets us pattern match very quickly if we need to without tags. Frontend tests are *JT. API tests are *AT. Unit Tests are *UT. Integration Tests are *IT
I wouldn't go with UT for unit tests but rather stick with *Test. Avoid lots of renames, keeps the established JUnit practice.
Philip Durbin 🚀 (Oct 16 2026 at 16:54):All I know is that Oliver is always grumpy about what we call things. :sweat_smile:
Can we please write down what to call things? I can start a new Zulip topic and a google doc! :smile:
Notification Bot (Oct 16 2026 at 16:56):8 messages were moved here from #dev > merge gdcc dataverse jsf tests into upstream by Oliver Bertuch.
Oliver Bertuch (Oct 16 2026 at 16:57):I recommend reading https://martinfowler.com/articles/practical-test-pyramid.html. Probably one of the most well known experts around testing. The pyramid scheme he's proposing (pun intended) is also quite well known in SE.
Philip Durbin 🚀 (Oct 16 2026 at 16:59):woof, long, authoritative!
Oliver Bertuch (Oct 16 2026 at 17:05):AI generated TL;DR — "The Practical Test Pyramid" (Ham Vocke, 2018)
Shape the suite like a pyramid: lots of fast unit tests → some integration/contract tests → very few
E2E. Avoid the ice-cream cone (slow, flaky, unmaintainable). Layer names don't matter much;
granularity + count ratios do.
Unit — most tests, no DB/FS/network. Test observable behaviour, not implementation, or they break
on every refactor. Skip trivial code. Wanting to test a private method = SRP violation, extract a
class.
Integration — one boundary at a time (DB, REST, queues, files). Run deps locally; fake third
parties with WireMock via test config. Never hit prod. Fakes drift from reality → next item.
Contract (Pact/CDC) — consumer writes tests for only what it needs, publishes a pact file, provider
runs it in their pipeline continuously. Kills cross-team API drift and gold-plating. Replaces the
WireMock test, doesn't duplicate it.
E2E — max confidence, worst cost: flaky, slow, no clear owner in a microservices org. Keep to the
1–3 journeys that carry core product value. Subcutaneous tests (REST-assured, just under the UI)
get most of the value with less pain.
Acceptance tests (given/when/then) are about user correctness, orthogonal to the pyramid — write
them as low as the scenario allows. Exploratory testing for what automation misses; automate each
bug found.
Rules of thumb: Arrange–Act–Assert everywhere; one condition per test; readability beats DRY (DAMP,
Rule of Three); test code deserves production-grade care; order pipeline stages by speed, not test
type; push tests down and delete high-level ones already covered below. Terminology is irreparably
ambiguous — agree on definitions within your team and move on.
Philip Durbin 🚀 (Oct 16 2026 at 18:38):Oliver Bertuch said:
AI generated TL;DR
@Oliver Bertuch did you read what AI generated? I hope you aren't being a meat proxy! :smile:
Oliver Bertuch (Oct 16 2026 at 18:49):Yes, I read it and I couldn't find any obvious flaws. No guarantees though.
Philip Durbin 🚀 (Oct 16 2026 at 19:05):Ok, good. Overall, this blog post seems to be a mix of terminology and recommendations.
Mostly I'm trying get us on the same page with terminology. Exactly this:
"Terminology is irreparably ambiguous — agree on definitions within your team and move on."
:smile:
Last updated: Nov 02 2026 at 07:01 UTC