Skip to content

Update ch11-03-test-organization.md #4337

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.

Sign up for GitHub

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

Open
mixmastamyk wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Update ch11-03-test-organization.md #4337

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d4ce342
Update ch11-03-test-organization.md
mixmastamyk Apr 16, 2025
d137cb7
Update ch11-03-test-organization.md
mixmastamyk Apr 16, 2025
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
4 changes: 2 additions & 2 deletions src/ch11-03-test-organization.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ As mentioned at the start of the chapter, testing is a complex discipline, and
different people use different terminology and organization. The Rust community
thinks about tests in terms of two main categories: unit tests and integration
tests. _Unit tests_ are small and more focused, testing one module in isolation
at a time, and can test private interfaces. _Integration tests_ are entirely
at a time, and can test private interfaces. _Integration tests_ are
external to your library and use your code in the same way any other external
code would, using only the public interface and potentially exercising multiple
modules per test.
Expand Down Expand Up @@ -76,7 +76,7 @@ to do so.

### Integration Tests

In Rust, integration tests are entirely external to your library. They use your
In Rust, integration tests are external to your library. They use your
library in the same way any other code would, which means they can only call
functions that are part of your library’s public API. Their purpose is to test
whether many parts of your library work together correctly. Units of code that
Expand Down