Streamline test pattern

[tobiasKaminsky]

I appreciate that we try to document he test. If we're writing a geherkin-style test scenarios, can we please use recognized way for this? https://support.smartbear.com/cucumberstudio/docs/bdd/write-gherkin-scenarios.html

Originally posted by @ezaquarii in https://github.com/nextcloud/android/pull/5465

--> This should be a discussion, if and how we want to use a test pattern for our tests I am ok with geherkin-style, but would also be fine with a test description above function and three steps "arrange", "act", "assert", but I guess the geherkin-style is more standardized, which could help us to write clean and simple test cases?

@ezaquarii @AndyScherzinger @Shagequi

[Kilian-Perisset]

I don't see the point of highly standardizing specific tests... I would follow the Android way, so :

• (Global samples) https://github.com/android/testing-samples
• (Testing samples for Junit4 in java) https://github.com/android/testing-samples/blob/master/ui/espresso/BasicSample/app/src/androidTest/java/com/example/android/testing/espresso/BasicSample/ChangeTextBehaviorTest.java
• (AOSP Java Code Style) https://source.android.com/setup/contribute/code-style#javatests-style-rules

[ezaquarii]

I'm not saying that gherkin is something we should enforce - that would be silly. Not everything suits BDD-style testing. Some components will be ok with simple function-based test, some will need elaborate test suites with hierarchies of setup and design documentation, we will have unit and integration tests.

My point was that if we creating BDD-style test, let's at least do it in a way familiar to wider audience and do not employ unexpected terminology. Gherkin is actually very recognizable with plenty of good examples we could always relate to - rejecting that existing hive knowledge is lost opportunity.

One of our higher meta-goals that I have in mind when massaging some tiny details into perfection is setting good example for future contributors. People are coming to us with from different levels of experience, knowledge, professionalism and motivation. Many of them will be seeing or using our concepts first time and I believe it would be beneficial if we could provide them with helpful reference points.

And last but not least, I try to be mindful of broken windows theory.

[AndyScherzinger]

TL;DR: let's not invent a Nc-specific test style/method but rely on "widely known" approaches

---

I agree with all of the above (at least I think I do).

as in:

• If we create BDD-style tests than we should do it in a way many potentially, future contributors might be familiar with
• Test type (unit, integration, system, whatever) have different target and concepts and thus differ in style

That said the links @Shagequi posted provide some pointers for a certain set of tests as well as @ezaquarii's link regarding Gherkin-styled test.