Skip to content
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

Merged
merged 4 commits into from
Oct 30, 2024
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 62 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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.
Copy link
Contributor

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.

Copy link
Member

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 🤔

- **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
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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).
Expand Down
Loading