-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Unit Testing Guidelines to CONTRIBUTING.md
for Scribe Android
#228
Changes from 2 commits
8b48a1b
39eb246
773bde2
c68760d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -143,6 +143,8 @@ Scribe-Android uses pre-commit hooks to maintain a clean and consistent codebase | |
|
||
## Testing [`⇧`](#contents) | ||
|
||
Writing unit tests is essential to guarantee the dependability, sustainability, and excellence of the Scribe Android codebase. Unit tests confirm that individual components of the application work as intended, detecting errors at an early stage, making the debugging process easier, and boosting assurance for upcoming modifications. An unchanging testing method helps new team members grasp project norms and anticipated actions. | ||
|
||
In addition to the [pre-commit](https://pre-commit.com/) hooks that are set up during the [development environment section](#dev-env), Scribe-Android includes a testing suite that should be ran before all pull requests and subsequent commits. Please run the following in the project root: | ||
|
||
```bash | ||
|
@@ -159,6 +161,66 @@ ktlint --format | |
|
||
<a id="issues-projects"></a> | ||
|
||
### Unit Testing Conventions for Scribe Android | ||
|
||
To maintain consistency and clarity in the Scribe Android codebase, we recommend you to follow these conventions when writing unit tests. These guidelines cover the organization, naming conventions, scope, and structure for unit tests. | ||
|
||
#### 1. Project Structure for Unit Tests | ||
|
||
- **Location**: Place all unit tests in the `src/test/java` directory, mirroring the structure of the `src/main/java` directory. For new classes or features, ensure their corresponding test classes follow the same package structure. | ||
- **Class Files**: Each class in `src/main/java` should have a dedicated test file in `src/test/java`, named by appending `Test` to the class name (e.g., `UserManager` → `UserManagerTest`). | ||
- **New Classes for Testing**: When a new utility or helper class is needed specifically for testing, place it under `src/test/java/utils` or `src/test/java/helpers`. | ||
|
||
#### 2. Naming Conventions for Tests | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thank you for adding examples in this section |
||
|
||
- **Test Methods**: Use descriptive names indicating expected behavior. Follow the format: | ||
|
||
```java | ||
@Test | ||
public void methodName_StateUnderTest_ExpectedBehavior() { | ||
// Test code here | ||
} | ||
``` | ||
|
||
Example: `saveUser_WithValidData_SavesUserCorrectly()`. | ||
|
||
- **Descriptive Names**: Avoid generic names like `testMethod1`. Focus on what’s being tested and the expected outcome, such as `calculateTotal_WithDiscount_AppliesDiscountCorrectly`. | ||
|
||
#### 3. Scope and Focus of Tests | ||
|
||
- **Single Responsibility**: Each test should cover only one behavior or scenario. For multiple behaviors, split them into separate test methods. | ||
- **Setup and Teardown**: Use `@Before` for initializing objects and `@After` for cleanup, ensuring tests run in isolation. | ||
|
||
```java | ||
@Before | ||
public void setUp() { | ||
// Initialize objects | ||
} | ||
|
||
@After | ||
public void tearDown() { | ||
// Cleanup objects | ||
} | ||
``` | ||
|
||
- **Mocking**: Use mocks (e.g., Mockito) to isolate the unit under test, especially with dependencies like databases, network requests, or services. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This project is setup with MockK so I recommend referring to that instead of Mockito |
||
|
||
#### 4. Writing Effective Tests | ||
|
||
- **AAA Pattern (Arrange, Act, Assert)**: Structure each test with three distinct parts: | ||
- **Arrange**: Set up the conditions. | ||
- **Act**: Execute the method under test. | ||
- **Assert**: Verify the result. | ||
|
||
- **Coverage of Edge Cases**: Write tests for both typical cases and edge cases, like `null` values or invalid data. | ||
|
||
#### 5. Test Documentation | ||
|
||
- **Comments**: Add comments when test logic is complex or non-intuitive. | ||
- **Assertions**: Use descriptive assertion methods (`assertTrue`, `assertEquals`, etc.) for clarity and include failure messages for custom assertions if necessary. | ||
|
||
Following these conventions ensures consistent, readable, and reliable unit tests, enhancing the quality of the Scribe Android codebase. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's good to highlight the importance of testing but this is very similar to the opening content of this section and could be removed. The shorter the docs are, the more likely people are to finish reading through them. |
||
|
||
# Issues and projects [`⇧`](#contents) | ||
|
||
The [issue tracker for Scribe-Android](https://github.com/scribe-org/Scribe-Android/issues) is the preferred channel for [bug reports](#bug-reports), [features requests](#feature-requests) and [submitting pull requests](#pull-requests). Scribe also organizes related issues into [projects](https://github.com/scribe-org/Scribe-Android/projects). | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This must be an Android project structure thing - I'm newer to Android - why is kotlin code put under java directories?
The unit tests I added as an example are under src/test/kotlin so a follow up will need to be moving the example to the correct structure if src/test/java is the desired structure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not actually sure on this either, @albendz :) Was the structure of the project that was forked. Maybe we could look into this in #223 where some renaming will happen 🤔