mirror of
https://github.com/logos-storage/logos-storage-docs-obsidian.git
synced 2026-01-03 13:53:13 +00:00
113 lines
3.1 KiB
Markdown
113 lines
3.1 KiB
Markdown
Some summary about testify assertions.
|
|
|
|
## `assert.Equal()` Function Signature
|
|
|
|
```go
|
|
func Equal(t TestingT, expected, actual interface{}, msgAndArgs ...interface{}) bool
|
|
```
|
|
|
|
### Parameters Breakdown:
|
|
|
|
1. **`t TestingT`** - The testing interface (first parameter)
|
|
2. **`expected interface{}`** - What you expect the value to be
|
|
3. **`actual interface{}`** - The actual value you're testing
|
|
4. **`msgAndArgs ...interface{}`** - Optional custom message and formatting arguments
|
|
|
|
## What is `suite.T()`?
|
|
|
|
When you're using testify's **test suite pattern**, `suite.T()` returns the underlying `*testing.T` instance associated with the current test method.
|
|
|
|
```go
|
|
type CodexArchiveDownloaderTestifySuite struct {
|
|
suite.Suite // Embeds testify's Suite type
|
|
// ... other fields
|
|
}
|
|
|
|
func (suite *CodexArchiveDownloaderTestifySuite) TestBasicSingleArchive() {
|
|
// suite.T() returns the *testing.T for this specific test method
|
|
assert.Equal(suite.T(), 1, downloader.GetTotalArchivesCount())
|
|
}
|
|
```
|
|
|
|
## Comparison: Suite vs Function-Based
|
|
|
|
### In Test Suite (what you're seeing):
|
|
```go
|
|
assert.Equal(suite.T(), expected, actual, "optional message")
|
|
```
|
|
|
|
### In Regular Function-Based Test:
|
|
```go
|
|
func TestSomething(t *testing.T) {
|
|
assert.Equal(t, expected, actual, "optional message")
|
|
}
|
|
```
|
|
|
|
## Why `suite.T()` is Needed
|
|
|
|
The testify suite embeds a `*testing.T`, but assertions need direct access to it for:
|
|
- Reporting failures
|
|
- Marking tests as failed
|
|
- Logging output
|
|
- Integration with Go's test runner
|
|
|
|
## Other Common Assert Functions
|
|
|
|
```go
|
|
// Basic equality
|
|
assert.Equal(t, expected, actual)
|
|
assert.NotEqual(t, expected, actual)
|
|
|
|
// Boolean checks
|
|
assert.True(t, condition)
|
|
assert.False(t, condition)
|
|
|
|
// Nil checks
|
|
assert.Nil(t, value)
|
|
assert.NotNil(t, value)
|
|
|
|
// Collection checks
|
|
assert.Len(t, collection, expectedLength)
|
|
assert.Contains(t, collection, element)
|
|
assert.Empty(t, collection)
|
|
|
|
// Error checks
|
|
assert.NoError(t, err)
|
|
assert.Error(t, err)
|
|
|
|
// Type checks
|
|
assert.IsType(t, expectedType, actual)
|
|
|
|
// All with optional custom messages
|
|
assert.Equal(t, 42, result, "The calculation should return 42")
|
|
assert.True(t, isValid, "Validation should pass for input: %s", input)
|
|
```
|
|
|
|
## `require` vs `assert`
|
|
|
|
Both take the same parameters, but behave differently on failure:
|
|
|
|
```go
|
|
// assert continues test execution on failure
|
|
assert.Equal(t, 1, count)
|
|
assert.True(t, isReady) // This will still run even if above fails
|
|
|
|
// require stops test execution immediately on failure
|
|
require.Equal(t, 1, count)
|
|
require.True(t, isReady) // This won't run if above fails
|
|
```
|
|
|
|
## In Your Code Context
|
|
|
|
```go
|
|
// Line 90 you're looking at:
|
|
assert.Equal(suite.T(), 1, downloader.GetTotalArchivesCount(), "Total archives count should be 1")
|
|
```
|
|
|
|
This means:
|
|
- **`suite.T()`** - The testing context from the suite
|
|
- **`1`** - Expected value
|
|
- **`downloader.GetTotalArchivesCount()`** - Actual value being tested
|
|
- **`"Total archives count should be 1"`** - Custom error message if assertion fails
|
|
|
|
The assertion will fail if `GetTotalArchivesCount()` returns anything other than `1`, and it will display your custom message along with the expected vs actual values. |