As many in the community know, @mmarciniak90 and @kkrawczyk123 provide excellent Quality Assurance across the ODK tools. They test all new code that is submitted and do a pass before each new release to make sure all of the new components work effectively together. It's largely thanks to them that the defect rate has been so low.
For Collect, they have proposed automating some of the tests that they currently do manually using Espresso at https://github.com/opendatakit/collect/pull/3066. This is the same tool developers already use for UI tests which means no new tools to support and the opportunity for more collaboration between developers and QA.
Let's have a call to define some conventions around how test files are structured, where test forms go, where helper methods go and so on. Some specific things I'd like to discuss:
- separate package for QA defined cases vs. organizing all tests into packages that match the source
- identifying the test cases -- are class names descriptive enough or should there be comments, links to issues? Could be as formal as Cucumber
- putting helper methods in a base class vs a utility class vs PageObject pattern
- using string IDs so the tests are robust in case of language change
I've already talked to @kkrawczyk123 @mmarciniak90 @Grzesiek2010 @seadowg about joining in. I know it's last minute but anyone else interested in Collect automated testing is welcome. @Mickys0918 I know you're working on some testing for your GSoC project so perhaps you'd be interested in joining as well. If you have other suggestions for the agenda (particularly @kkrawczyk123 and @mmarciniak90), please comment below 
Let's make this a video call in https://meet.google.com/tia-sibu-eht?authuser=1