Skip to content

Latest commit

 

History

History
107 lines (86 loc) · 3.87 KB

CONTRIBUTING.md

File metadata and controls

107 lines (86 loc) · 3.87 KB
Raw

Contributing

  • Find an issue in the Issues Tab and assign it to yourself. Feel free to create one if it doesn't exist.
  • Fork the repository. This means that you will have a copy of the repository under your-GitHub-username/repository-name.
  • Clone the repository to your local machine using git clone https://github.com/github-username/repository-name.git.
  • Create a branch against main
  • Create a PR to main. PullRequests must pass the following checks;
    • Must be approved by a code owner
    • Must pass all CI Checks
    • Must include updated tests
    • Must have every conversation resolved before merging
  • We encourage you to use git rebase for a linear history
  • To ensure small PRs, Work on only one layer ie.
    • If you are working on the usecase;
      • Create the usecase, the repository and a repository implementation in the domain layer only
    • If you are working on the UI
      • Work on the UI and navigation if its an empty screen
      • Work on the Design and ViewModel if its UI implementation ticket
    • If you are working on the data layer work on the data layer only.

Naming conventions

  • All Compose navigation Destination components must be suffixed with Screen ie. HomeScreen
  • All components inside a screen must be suffixed with suffixed with the word Component ie. SponsorsComponent
  • All ViewModels must be suffixed with the word ViewModel ie. HomeViewModel
  • All useCases must be prefixed with a get or set depending on functionality and suffixed with Usecase ie. GetSponsorsUsecase
  • All repositories must be suffixed with Repository. ie. SponsorsRepository
  • All repository implementations must be suffixed with DataRepository ie. SponsorsDataRepository
  • All public functions in the ViewModel must be prefixed with on and suffixed with action ie. onSignInAction()
  • All models should suffix the layer then model. ie. SponsorsDataModel or SponsorsDomainModel or SponsorsPresentationModel
  • All mappers should follow the pattern model-layerFrom-layerTo-mapper ie. SponsorDataToDomainMapper
  • All string resources will be in snake case ie. my_awesome_string
  • String resources for a screen should be prefixed with screen name ie. home_screen_title

Coding Style

DO

  • ViewModel and view will fall under the feature's Ui package
  • All Ui components will be under feature's components package
  • Include tests if you are making changes to the following;
    • ViewModel
    • Repository
    • Usecase
    • Mappers
  • Format your changed files COMMAND+OPTION+L for mac users or CTRL+ALT+L
  • Include a preview for all UI components.

DON'T

  • Don't include the word impl in a repository implementation name. Use DataRepository instead.

Testing

Composables

Write composable(s) tests when pushing a PR in this repository. This can be easily be done by:

  • Adding a testTag(""") on a composable
Modifier.testTag("heading")
  • Then write a test in this format ()
@RunWith(RobolectricTestRunner::class)
@Config(instrumentedPackages = ["androidx.loader.content"])
class YOUR_TEST_FILE_NAME {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Before
    @Throws(Exception::class)
    fun setUp() {
        ShadowLog.stream = System.out
    }

    @Test
    fun `YOUR TEST NAME HERE`() {

        composeTestRule.setContent {
            DroidconKE2023Theme {
                YOUR_COMPOSABLE_HERE()
            }
        }

        // SAMPLE TESTS
        composeTestRule.onNodeWithTag(TEST_TAG_VALUE_HERE).assertIsDisplayed()
        composeTestRule.onNodeWithTag(TEST_TAG_VALUE_HERE).assertTextEquals(SOME_VALUE_HERE)

        // MORE TESTS IF YOU WANT
    }
}