The better alternative is to use an actual programming language. There are hundred things that can go wrong, the IDE won't help you a bit, and it's a mmajor time waster. What happens here is that someone at GitHub just made up a terrible programming language disguised as YAML. What we are doing is writing a programming script. Look, we want to make a computer do stuff that are not trivial. I use quotes here because I think that "configuration file" here is a lie. My biggest frustration by far was due to those YAML "configuration files". Now if you want to start putting more emphasis on writing more unit tests, having this infrastructure in place with GitHub Action is a nice first step. To understand why it's an anti-pattern, read the Google Testing blog: The testing pyramid looks like this and won't probably last as long as the ones in Egypt: Unfortunately there is a common anti-pattern in the Android world where not enough emphasis is put on the unit tests. This is why the recommended strategy is to have a testing pyramid where the emphasis is put on writing a lot of fast simple unit tests: Unit tests are fast, easier to write and lead faster to the discovery and fix of the bug when they fail. Something to keep in mind if you have an Android project is that my workflow allows you to run the unit tests on GitHub, but not the integration tests / automated GUI tests also called Android instrumentation tests. Read the docs about the Gradle Command ActionĪ problem I encountered in the DEV-Android app is that it had very few unit tests To know more about creating your own Gradle tasks, follow the gentle tutorial at Open the Actions tab on GitHub and if you are lucky you will see this after a while:.gradlew -dry-run runOnGitHub to see quickly what tasks would be executed without actually running them. gradlew runOnGitHub and check it does what you want. you document what will appear when you run.So be sure to customize it for your needs. This is the crucial step that will depend from project to project. In this example we run the linter and the unit tests in the app module. you define via dependsOn() which tasks should be executed before runOnGitHub. you register a new task called runOnGitHub.Enter fullscreen mode Exit fullscreen mode
0 Comments
Leave a Reply. |