Use Android Studio 4.2+.
Install Node.js (e.g. via package manager) which is needed for the prettier
plugin we use to format XML
files.
The codebase follows google-java-format instead of the Kotlin coding conventions because google-java-format is strict and deterministic, and therefore removes formatting as a concern for developers altogether.
If you would like Android Studio to help format your code, follow these steps to set up your Android Studio:
Settings
(or Preferences
), select the Plugins
category, click the Marketplace
tab, search for the ktfmt
plugin, and click the Install
buttonSettings
(or Preferences
), go to Editor
→ ktfmt Settings
, tick Enable ktfmt
, change the Code style
to Google (Internal)
, and click OK
Settings
(or Preferences
), go to Editor
→ Code Style
→ Kotlin
→ Tabs and Indents
, set Tab size
, Indent
and Continuation indent
to 2
, and click OK
.Settings
(or Preferences
), go to Editor
→ Code Style
→ Kotlin
→ Imports
, in Top-level Symbols
and Java statics and Enum Members
sections select Use single name import
option, remove all the rules in Packages to Use Imports with '*'
and Import Layout
sections and click OK
.Now you can go to Code
→ Reformat code
, or press Ctrl+Alt+L
(⌘+⌥+L
for Mac) to automatically format code in Android Studio.
Note that you don’t have to do any of these. You could rely on spotless to format any code you want to push. For details see below.
We use prettier’s XML plugin to format the XML code. At the moment we have not discovered an Android Studio style configuration that would produce the same result. As a result, please run ./gradlew spotlessApply
to format the XML files.
The common library module contains code that is shared across other modules e.g. engine, datacapture . During development you might want to make updates to the common module and test them on the dependant library.
To make developing/testing these type of updates more efficient, it is recommended to replace the implementation(Dependencies.androidFhirCommon)
dependency configuration with implementation(project(":common"))
in the build.gradle.kts
file. Then once the PR with the changes to common is merged in and the artifact published, you can revert.
Remember to update the Versions.androidFhirCommon
variable with the correct/new version of the published artifact in the Dependencies.kt
file
We follow the following naming convention for our test cases:
methodName_conditionUnderTest_expectedBehavior
For example:
isNumberEven_one_shouldReturnFalse
isNumberEven_two_shouldReturnTrue
For UI automation, “Page object framework” is used, Below is the structure of framework:
Structure:
Pages: Here all screens objects ,identifiers and functions are defined
Tests: All tests for all screens are written here
Testdata: Data which is used for testing mentioned here
Setup QA tests:
Precondition:
open class BaseTest {
@get:Rule
val activityRule: ActivityScenarioRule<MainActivity> =
ActivityScenarioRule(MainActivity::class.java)
}
Write testcase:
private val pageName = "Add Patient"
private val addPatientButton = R.id.add_patient
fun validate_page() {
}
onView(allOf(withText(R.string.add_patient), withText(pageName))).check(matches(isDisplayed()))
class AddPatientTest() : BaseTest() {
private val addPatientPage: AddPatientPage = AddPatientPage()
}
fun shouldBeAbleToValidatePage() {
addPatientPage.validate_page()
}
precondition: device or emulator should be connected
Right click on test file created in step 6 -> Run ‘AddPatientTest’
To write Screenshot Tests:
@get:Rule var activityTestRule = ActivityTestRule(MainActivity::class.java, false, false)
val grantPermissionRule: GrantPermissionRule =
GrantPermissionRule.grant(
android.Manifest.permission.READ_EXTERNAL_STORAGE,
android.Manifest.permission.WRITE_EXTERNAL_STORAGE
)
fun testScreenshotEntireActivity() {
}
val activity = activityTestRule.launchActivity(null))
`
val view = activityTestRule.activity.findViewById
` snapActivity(activity).setName(“Registered Patient List”).record() `
` snap(view).setName(“sample_view_test”).record() `
To Run Screenshot Tasks below:
clean<App Variant>Screenshots
- Clean last generated screenshot report
pull<App Variant>Screenshots
- Pull screenshots from your device
record<App Variant>ScreenshotTest
- Installs and runs screenshot tests, then records their output for later verification
run<App Variant>ScreenshotTest
- Installs and runs screenshot tests, then generates a report
verify<App Variant>ScreenshotTest
- Installs and runs screenshot tests, then verifies their output against previously recorded screenshots
To run through ./gradlew below is the command:
$ ./gradlew runDebugAndroidTestScreenshotTest
To run screenshot test for specific application:
$ ./gradlew Demo:runDebugAndroidTestScreenshotTest
To directory run screenshot test using android studio:
Right click either the test folder or the test file in Android Studio and click ‘Run Tests in …’:
We use Spotless to maintain the Java/Kotlin coding style in the codebase. Run the following command to check the codebase:
./gradlew spotlessCheck
and run the following command to apply fixes to the violations:
./gradlew spotlessApply
Spotless maintains the license headers for Kotlin files. Use addlicense to maintain license headers in other files:
addlicense -c "Google LLC" -l apache .
To run the task locally:
$./gradlew jacocoTestReport
To run the task locally for a specific module:
$./gradlew :<module>:jacocoTestReport
The Jacoco test coverage report will be in the folder <module>/build/reports/jacoco/jacocoTestReport
.
We use Ruler to generate reports on the APK size of our demo/catalog app. This allows us to track increases in our SDK’s library size.
To generate these reports, run the analyzeReleaseBundle
task on the project you are interested in. For example:
./gradlew :demo:analyzeReleaseBundle
The task will print a path to an HTML report, which is human-readable, and a JSON report, which can be used for automation.
PRs can only be merged if all of the following requirements are met:
Each GitHub build of the project also contains a maven repository. You can access unreleased features by downloading it and including it in your project. To acquire the maven repository, go the the actions page, and click on the build you want. In the build artifacts
dropdown, you will find a maven-repository.zip
file. After downloading and extracting it to a local folder, you can add it to your gradle setup via:
repositories {
maven {
url "file:///<path to the unzipped folder>"
}
}
These artifacts are versioned as a combination of the current version + buildid (e.g. 0.1.0-alpha01-build_123
). You can find the version in the zip file by checking the contents of it and update your build file to match that version.
Build failed java heap space
Set org.gradle.jvmargs=-Xmx2048m
in project gradle.properties . If it still fails you can further increase the memory.
More than one file was found with OS independent path ‘mozilla/public-suffix-list.txt’.
Add this line to the packagingOptions in the build.gradle of you app
packagingOptions {
exclude 'mozilla/public-suffix-list.txt'
}
===
naming convention for view snake_case
how to run tests
This section defines the process one goes through when making changes to any of the dependent libraries on the FHIR SDK. An example of a library is the Workflow Library.
Step 1:
Step 2:
Step 3:
Step 4:
NB: For a specific example on working with FHIR SDK’s Common Library during development, see Common Library.