From 8c9f2faa0061784ede9ec2f6271e8f33a638f40c Mon Sep 17 00:00:00 2001 From: UnknownSuperficialNight <88142731+UnknownSuperficialNight@users.noreply.github.com> Date: Fri, 4 Oct 2024 16:39:30 +1300 Subject: [PATCH 01/11] Init commit of CONTRIBUTING.md --- CONTRIBUTING.md | 113 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..0beec982 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,113 @@ +# Rodio Development Guide + +## Quick Start + +1. Install [Rust](https://www.rust-lang.org/tools/install) +2. Clone the repository: `git clone https://github.com/RustAudio/rodio.git` +3. Navigate to the project: `cd rodio` +4. Build the project: `cargo build` + +## Project Structure + +src/: +- `source/`: Audio source implementations +- `decoder/`: Audio format decoders +- `sink/`: Audio playback and mixing +- `dynamic_mixer/`: Real-time audio mixing +- `spatial/`: Spatial audio capabilities + +## Coding Guidelines + +- Follow [Rust API Guidelines](https://rust-lang.github.io/api-guidelines/) +- Use `rustfmt` for formatting +- Implement `Source` trait for new audio sources +- Use `Sink` for playback management + +## Common Tasks + +### Adding a New Audio Source or Effect + +1. Create a new file in `src/source/` +2. Implement the `Source` trait to define how audio samples are generated or modified +3. Consider implementing sources like oscillators, noise generators, or effects like amplification, filtering, or distortion +4. Optimize for performance, especially for real-time processing in effects +5. Add unit tests/benchmarks where applicable to ensure proper functionality and performance + +### Implementing a New Decoder + +1. Add new module in `src/decoder/` +2. Implement necessary traits (e.g., `Decoder`) to handle specific audio formats +3. Focus on efficiently parsing audio file headers and decoding compressed audio data +4. Update `src/decoder/mod.rs` to integrate the new decoder + +## Testing + +- Write unit tests for each new function +- Add integration tests for end-to-end scenarios +- Run tests: `cargo test` + +## Documentation + +- Add inline documentation to all public items +- Generate docs: `cargo doc --open` +- Contribute examples to `examples/` + +## Contribution Workflow + +1. Fork the repository on GitHub +2. Clone your fork locally: `git clone https://github.com/YOUR_USERNAME/rodio.git` +3. Create a feature branch: `git checkout -b feature/your-feature-name` +4. Make changes and add tests where applicable (Dont be afraid to ask for help) +5. Ensure code quality: + - Run `cargo fmt` to format your code + - Run `cargo clippy` to check for common mistakes + - Run `cargo test` to ensure all tests pass (Not strictly necessary) + - Run `cargo bench` to run benchmarks (Not strictly necessary) +6. Commit your changes following these guidelines: (`git commit`) + - Write clear, concise commit messages + - Limit the first line to 50 characters + - Provide a detailed description after a blank line, if necessary + - Reference relevant issue numbers (e.g., "Fixes #123") + - Separate logical changes into multiple commits + - Avoid commits with unrelated changes + Example: + ``` + Add spatial audio support for stereo sources + + - Implement SpatialSource struct + - Add panning and distance attenuation + - Update documentation for spatial audio usage + + Fixes #456 + ``` +7. Push your changes to your fork: `git push origin feature/your-feature-name` +8. Create a pull request on GitHub + +Don't be afraid to ask for help at any point in the process! You can: +- Ask questions in your pull request +- Open an issue for guidance/questions + + +## Getting Help / Got a question? + +- Open an issue on GitHub +- Join the Rust Audio Discord + +## Useful Commands + +- Format: `cargo fmt` - Automatically formats the code according to Rust style guidelines +- Lint: `cargo clippy` - Runs the Clippy linter to catch common mistakes and improve code quality +- Benchmark: `cargo bench` - Executes performance benchmarks for the project + +For more detailed information, refer to the full documentation and source code. + +## Disclaimer + +Please note that the guidelines and practices outlined in this document +are not strict rules. They are general recommendations to promote +consistency and quality in contributions. + +We understand that every situation is unique and encourage contributors +to use their best judgment. If you have any doubts or questions about +how to approach a particular task or contribution, don't hesitate to +reach out to the maintainers for guidance. From c0066f9445678d99487a8fced040bbbda8e2eef3 Mon Sep 17 00:00:00 2001 From: UnknownSuperficialNight <88142731+UnknownSuperficialNight@users.noreply.github.com> Date: Fri, 4 Oct 2024 17:07:38 +1300 Subject: [PATCH 02/11] Updates a few changes --- CONTRIBUTING.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0beec982..d6dcf0bf 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -42,7 +42,7 @@ src/: ## Testing -- Write unit tests for each new function +- Write unit tests for each new function (if applicable) - Add integration tests for end-to-end scenarios - Run tests: `cargo test` @@ -83,15 +83,12 @@ src/: 7. Push your changes to your fork: `git push origin feature/your-feature-name` 8. Create a pull request on GitHub -Don't be afraid to ask for help at any point in the process! You can: -- Ask questions in your pull request -- Open an issue for guidance/questions - - ## Getting Help / Got a question? - Open an issue on GitHub - Join the Rust Audio Discord +- Ask questions in your pull request +- Open an issue for guidance/questions ## Useful Commands From 400dfe5a6e171b7e08f35f0aa8f0c5698c94ec3d Mon Sep 17 00:00:00 2001 From: UnknownSuperficialNight <88142731+UnknownSuperficialNight@users.noreply.github.com> Date: Fri, 4 Oct 2024 23:52:22 +1300 Subject: [PATCH 03/11] Add Rust performance book mention --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d6dcf0bf..5e6065b0 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -30,7 +30,7 @@ src/: 1. Create a new file in `src/source/` 2. Implement the `Source` trait to define how audio samples are generated or modified 3. Consider implementing sources like oscillators, noise generators, or effects like amplification, filtering, or distortion -4. Optimize for performance, especially for real-time processing in effects +4. Optimize for [performance](https://nnethercote.github.io/perf-book/introduction.html), especially for real-time processing in effects 5. Add unit tests/benchmarks where applicable to ensure proper functionality and performance ### Implementing a New Decoder From c19faddd3236d322b7f3ee7c60c530e169ac81d2 Mon Sep 17 00:00:00 2001 From: UnknownSuperficialNight <88142731+UnknownSuperficialNight@users.noreply.github.com> Date: Fri, 4 Oct 2024 23:56:03 +1300 Subject: [PATCH 04/11] Add 'Useful External Resources' Section --- CONTRIBUTING.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5e6065b0..84fa9e43 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -98,6 +98,12 @@ src/: For more detailed information, refer to the full documentation and source code. +## Useful External Resources + +- [Rust API Guidelines](https://rust-lang.github.io/api-guidelines/) +- [Rust Performance Book](https://nnethercote.github.io/perf-book/introduction.html) +- [Rust Audio Discord](https://discord.com/invite/8qW6q2k) + ## Disclaimer Please note that the guidelines and practices outlined in this document From 41db8554fb36154016d3d732a14e81178d3d9f5d Mon Sep 17 00:00:00 2001 From: UnknownSuperficialNight <88142731+UnknownSuperficialNight@users.noreply.github.com> Date: Sat, 5 Oct 2024 00:10:37 +1300 Subject: [PATCH 05/11] Add guidelines for TDD, PR workflow, and optimization - Start with tests for new features - Open draft PR after initial functionality - Refactor, benchmark, and optimize - Offer support for test creation --- CONTRIBUTING.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 84fa9e43..f1edf2ff 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -30,8 +30,10 @@ src/: 1. Create a new file in `src/source/` 2. Implement the `Source` trait to define how audio samples are generated or modified 3. Consider implementing sources like oscillators, noise generators, or effects like amplification, filtering, or distortion -4. Optimize for [performance](https://nnethercote.github.io/perf-book/introduction.html), especially for real-time processing in effects -5. Add unit tests/benchmarks where applicable to ensure proper functionality and performance +4. Begin with a test for your new feature. This approach ensures your PR is ready and simplifies development. Don't worry about optimizing initially; focus on functionality. +5. Once your feature works, celebrate your progress! 🎉 Open a draft PR at this stage - we're here to assist with refactoring and optimization. +6. Refactor your code, add benchmarks, and work on improving performance, especially for real-time processing in effects. Refer to the [Rust Performance Book](https://nnethercote.github.io/perf-book/introduction.html) for optimization techniques. +7. If you're unsure about creating tests, implement your feature first, then open a PR asking for guidance. We're happy to help! ### Implementing a New Decoder From dc85fe8045c08b8341e686f5745b56da4bad2b1b Mon Sep 17 00:00:00 2001 From: UnknownSuperficialNight <88142731+UnknownSuperficialNight@users.noreply.github.com> Date: Sat, 5 Oct 2024 02:32:13 +1300 Subject: [PATCH 06/11] Update testing guidelines in CONTRIBUTING.md - Encourage use of temporary unit tests during development - Clarify that rough, non-comprehensive tests are acceptable - Allow inclusion of temporary tests in pull requests - Explain rationale for removing tests before final merge: - Easier refactoring - Reduced necessity due to Rust's type system - Maintain instruction to run tests with 'cargo test' --- CONTRIBUTING.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f1edf2ff..c2bd18c7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,10 +2,9 @@ ## Quick Start -1. Install [Rust](https://www.rust-lang.org/tools/install) -2. Clone the repository: `git clone https://github.com/RustAudio/rodio.git` -3. Navigate to the project: `cd rodio` -4. Build the project: `cargo build` +1. Clone the repository: `git clone https://github.com/RustAudio/rodio.git` +2. Navigate to the project: `cd rodio` +3. Build the project: `cargo build` ## Project Structure @@ -44,8 +43,12 @@ src/: ## Testing -- Write unit tests for each new function (if applicable) -- Add integration tests for end-to-end scenarios +- Feel free to write temporary unit tests during development if they help you verify functionality +- These tests can be rough and don't need to be comprehensive - they're just development aids +- It's okay to include these temporary unit tests in your pull request +- We'll remove these tests before merging into the main codebase, primarily because: + - They can make refactoring more difficult as tests may break with code changes + - Rust's robust type system reduces the need for extensive unit testing compared to dynamically typed languages - Run tests: `cargo test` ## Documentation From b6a90594aa4fcc2412ae6518db68b35e75b2e830 Mon Sep 17 00:00:00 2001 From: UnknownSuperficialNight <88142731+UnknownSuperficialNight@users.noreply.github.com> Date: Sat, 5 Oct 2024 02:34:56 +1300 Subject: [PATCH 07/11] Remove 'Ensure code quality' --- CONTRIBUTING.md | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c2bd18c7..0112a0f7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -63,12 +63,7 @@ src/: 2. Clone your fork locally: `git clone https://github.com/YOUR_USERNAME/rodio.git` 3. Create a feature branch: `git checkout -b feature/your-feature-name` 4. Make changes and add tests where applicable (Dont be afraid to ask for help) -5. Ensure code quality: - - Run `cargo fmt` to format your code - - Run `cargo clippy` to check for common mistakes - - Run `cargo test` to ensure all tests pass (Not strictly necessary) - - Run `cargo bench` to run benchmarks (Not strictly necessary) -6. Commit your changes following these guidelines: (`git commit`) +5. Commit your changes following these guidelines: (`git commit`) - Write clear, concise commit messages - Limit the first line to 50 characters - Provide a detailed description after a blank line, if necessary @@ -85,8 +80,8 @@ src/: Fixes #456 ``` -7. Push your changes to your fork: `git push origin feature/your-feature-name` -8. Create a pull request on GitHub +6. Push your changes to your fork: `git push origin feature/your-feature-name` +7. Create a pull request on GitHub ## Getting Help / Got a question? From dd3e8de93acc2684680142cb23477a453e3cde5e Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Sat, 5 Oct 2024 02:06:39 +0200 Subject: [PATCH 08/11] Contributing.md adds section on integration tests, improve new source section Specifically notes some example tests and how they test. Also mentions sometimes you just have to listen, recommends adding example for that. Author: dvdsk Date: Sat Oct 5 02:06:39 2024 +0200 --- CONTRIBUTING.md | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0112a0f7..cab4b036 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -27,12 +27,14 @@ src/: ### Adding a New Audio Source or Effect 1. Create a new file in `src/source/` -2. Implement the `Source` trait to define how audio samples are generated or modified -3. Consider implementing sources like oscillators, noise generators, or effects like amplification, filtering, or distortion -4. Begin with a test for your new feature. This approach ensures your PR is ready and simplifies development. Don't worry about optimizing initially; focus on functionality. -5. Once your feature works, celebrate your progress! 🎉 Open a draft PR at this stage - we're here to assist with refactoring and optimization. -6. Refactor your code, add benchmarks, and work on improving performance, especially for real-time processing in effects. Refer to the [Rust Performance Book](https://nnethercote.github.io/perf-book/introduction.html) for optimization techniques. -7. If you're unsure about creating tests, implement your feature first, then open a PR asking for guidance. We're happy to help! +1. Implement the `Source` trait to define how audio samples are generated or modified +1. Consider implementing sources like oscillators, noise generators, or effects like amplification, filtering, or distortion +1. If your contribution creates sound you should give it a public (factory) function that constructs it. If its an effect then add a method with default implementation for it in the `Source` trait. +1. Begin with a test for your new feature (see the [Testing](#testing)). This approach ensures your PR is ready and simplifies development. Don't worry about optimizing initially; focus on functionality. +1. Once your feature works, celebrate your progress! 🎉 Open a draft PR at this stage - we're here to assist with refactoring and optimization. +1. Refactor your code, add benchmarks, and work on improving performance, especially for real-time processing in effects. Refer to the [Rust Performance Book](https://nnethercote.github.io/perf-book/introduction.html) for optimization techniques. +1. Finally add some documentation and an example. For details see [Documentation]($documentation) +1. If you're unsure about creating tests, implement your feature first, then open a PR with what you have asking for guidance. We're happy to help! ### Implementing a New Decoder @@ -49,13 +51,25 @@ src/: - We'll remove these tests before merging into the main codebase, primarily because: - They can make refactoring more difficult as tests may break with code changes - Rust's robust type system reduces the need for extensive unit testing compared to dynamically typed languages +- We love integration tests but they can be hard to write. If you have trouble adding one its fine to leave it out. If you do add one create a new file for it in `tests/`. + +The integration test do not create sound though your speakers instead you write +code that examines the produced *samples*. Some examples: + - The `tests/wav_test.rs` test simply checks if the decoder produces nonzero samples. + - The test `seek_does_not_break_channel_order` in `tests/seek.rs` uses a + beeping sound that alternates between two channel. It seeks to a + point where we know only the second channel should make sound. Then we check + if the first channel is silent while the second is not. +- Its impossible to write a test that checks if something sounds "good". We + recommend adding an example that *does* produces sound and listening as a + test. - Run tests: `cargo test` ## Documentation -- Add inline documentation to all public items +- Add inline documentation to all public items. - Generate docs: `cargo doc --open` -- Contribute examples to `examples/` +- Add an example. That could be as part of the inline documentation or a more complex scenario in `examples/` ## Contribution Workflow From d57e410ca77998342d568a23445d2dd7765905bf Mon Sep 17 00:00:00 2001 From: UnknownSuperficialNight <88142731+UnknownSuperficialNight@users.noreply.github.com> Date: Sat, 5 Oct 2024 15:06:27 +1300 Subject: [PATCH 09/11] Add Contributing guide and Integration Test guidelines - Link to CONTRIBUTING.md in project root - New Integration Tests section: - Avoid sound output in tests - Tips for testing audio sources - Suggest examples for audible features - Note challenges in automated audio testing --- CONTRIBUTING.md | 15 +++++++++++++++ README.md | 4 ++++ 2 files changed, 19 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0112a0f7..833dc1e0 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -51,6 +51,21 @@ src/: - Rust's robust type system reduces the need for extensive unit testing compared to dynamically typed languages - Run tests: `cargo test` +### Integration Tests + +When possible, add integration tests for your new features. Keep in mind: + +- Typically, these tests should not produce actual sound output (i.e., avoid using `Sink` or `Stream`). +- For new audio sources: + - Verify that samples have changed from their initial state. + - Check if samples are non-zero where appropriate. + - Look for expected patterns or characteristics in the audio data. +- Be aware that many aspects of audio processing are challenging to verify automatically. +- For features requiring audible verification: + - Create an example in the `examples/` directory that demonstrates the functionality. + - These examples can produce sound for manual testing. + - Document the expected behavior in the example's comments. + ## Documentation - Add inline documentation to all public items diff --git a/README.md b/README.md index 91b03693..81c17a56 100644 --- a/README.md +++ b/README.md @@ -24,6 +24,10 @@ See [the docs](https://docs.rs/rodio/latest/rodio/#alternative-decoder-backends) Rodio uses `cpal` to send audio to the OS for playback. On Linux `cpal` needs the ALSA development files. These are provided as part of the libasound2-dev package on Debian and Ubuntu distributions and alsa-lib-devel on Fedora. +# Contributing + +For information on how to contribute to this project, please see our [Contributing Guide](https://github.com/RustAudio/rodio/CONTRIBUTING.md). + ## License [License]: #license From 0aa7f5e7036d8bfc2473c9ee3885efee58ab7dc1 Mon Sep 17 00:00:00 2001 From: UnknownSuperficialNight <88142731+UnknownSuperficialNight@users.noreply.github.com> Date: Sat, 5 Oct 2024 15:24:58 +1300 Subject: [PATCH 10/11] Merge: Integrate 'Integration Tests' from user dvdsk - Incorporate Integration Tests contributed by dvdsk - Add leading numbers to bullet points mistakenly commited without numbering --- CONTRIBUTING.md | 39 ++++++++++++++++----------------------- 1 file changed, 16 insertions(+), 23 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c400c74d..f1c220f6 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -27,14 +27,14 @@ src/: ### Adding a New Audio Source or Effect 1. Create a new file in `src/source/` -1. Implement the `Source` trait to define how audio samples are generated or modified -1. Consider implementing sources like oscillators, noise generators, or effects like amplification, filtering, or distortion -1. If your contribution creates sound you should give it a public (factory) function that constructs it. If its an effect then add a method with default implementation for it in the `Source` trait. -1. Begin with a test for your new feature (see the [Testing](#testing)). This approach ensures your PR is ready and simplifies development. Don't worry about optimizing initially; focus on functionality. -1. Once your feature works, celebrate your progress! 🎉 Open a draft PR at this stage - we're here to assist with refactoring and optimization. -1. Refactor your code, add benchmarks, and work on improving performance, especially for real-time processing in effects. Refer to the [Rust Performance Book](https://nnethercote.github.io/perf-book/introduction.html) for optimization techniques. -1. Finally add some documentation and an example. For details see [Documentation]($documentation) -1. If you're unsure about creating tests, implement your feature first, then open a PR with what you have asking for guidance. We're happy to help! +2. Implement the `Source` trait to define how audio samples are generated or modified +3. Consider implementing sources like oscillators, noise generators, or effects like amplification, filtering, or distortion +4. If your contribution creates sound you should give it a public (factory) function that constructs it. If its an effect then add a method with default implementation for it in the `Source` trait. +5. Begin with a test for your new feature (see the [Testing](#testing)). This approach ensures your PR is ready and simplifies development. Don't worry about optimizing initially; focus on functionality. +6. Once your feature works, celebrate your progress! 🎉 Open a draft PR at this stage - we're here to assist with refactoring and optimization. +7. Refactor your code, add benchmarks, and work on improving performance, especially for real-time processing in effects. Refer to the [Rust Performance Book](https://nnethercote.github.io/perf-book/introduction.html) for optimization techniques. +8. Finally add some documentation and an example. For details see [Documentation]($documentation) +9. If you're unsure about creating tests, implement your feature first, then open a PR with what you have asking for guidance. We're happy to help! ### Implementing a New Decoder @@ -51,34 +51,27 @@ src/: - We'll remove these tests before merging into the main codebase, primarily because: - They can make refactoring more difficult as tests may break with code changes - Rust's robust type system reduces the need for extensive unit testing compared to dynamically typed languages -- We love integration tests but they can be hard to write. If you have trouble adding one its fine to leave it out. If you do add one create a new file for it in `tests/`. - -The integration test do not create sound though your speakers instead you write -code that examines the produced *samples*. Some examples: - - The `tests/wav_test.rs` test simply checks if the decoder produces nonzero samples. - - The test `seek_does_not_break_channel_order` in `tests/seek.rs` uses a - beeping sound that alternates between two channel. It seeks to a - point where we know only the second channel should make sound. Then we check - if the first channel is silent while the second is not. -- Its impossible to write a test that checks if something sounds "good". We - recommend adding an example that *does* produces sound and listening as a - test. -- Run tests: `cargo test` ### Integration Tests When possible, add integration tests for your new features. Keep in mind: -- Typically, these tests should not produce actual sound output (i.e., avoid using `Sink` or `Stream`). +- Integration tests do not create sound through your speakers. Instead, you write code that examines the produced *samples*. - For new audio sources: - Verify that samples have changed from their initial state. - Check if samples are non-zero where appropriate. - Look for expected patterns or characteristics in the audio data. +- Examples of integration tests: + - The `tests/wav_test.rs` test simply checks if the decoder produces nonzero samples. + - The test `seek_does_not_break_channel_order` in `tests/seek.rs` uses a beeping sound that alternates between two channels. It seeks to a point where we know only the second channel should make sound. Then we check if the first channel is silent while the second is not. - Be aware that many aspects of audio processing are challenging to verify automatically. -- For features requiring audible verification: +- It's impossible to write a test that checks if something sounds "good". For features requiring audible verification: - Create an example in the `examples/` directory that demonstrates the functionality. - These examples can produce sound for manual testing. - Document the expected behavior in the example's comments. +- We love integration tests but they can be hard to write. If you have trouble adding one its fine to leave it out. If you do add one create a new file for it in `tests/`. +- Run tests: `cargo test` +- Run examples: `cargo run --example ` ## Documentation From ab66761e9129cc2bd8ff883b331358309665ac6a Mon Sep 17 00:00:00 2001 From: UnknownSuperficialNight <88142731+UnknownSuperficialNight@users.noreply.github.com> Date: Sun, 6 Oct 2024 15:38:31 +1300 Subject: [PATCH 11/11] Rename Testing to Unit Tests --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f1c220f6..269a961e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -43,7 +43,7 @@ src/: 3. Focus on efficiently parsing audio file headers and decoding compressed audio data 4. Update `src/decoder/mod.rs` to integrate the new decoder -## Testing +### Unit Tests - Feel free to write temporary unit tests during development if they help you verify functionality - These tests can be rough and don't need to be comprehensive - they're just development aids