Files that changed from the base of the PR and between d23da62 and 4486c1a.

• database/console/migrate_command_test.go (2 hunks)
• database/console/migrate_fresh_command_test.go (2 hunks)
• database/console/migrate_refresh_command_test.go (2 hunks)
• database/console/migrate_reset_command_test.go (2 hunks)
• database/console/migrate_rollback_command_test.go (3 hunks)
• database/console/migrate_status_command_test.go (3 hunks)
• database/factory_test.go (1 hunks)
• database/gorm/query_test.go (10 hunks)
• database/gorm/test_utils.go (12 hunks)
• database/gorm/test_utils_test.go (0 hunks)
• database/gorm/to_sql_test.go (1 hunks)
• database/migration/schema_test.go (1 hunks)
• database/orm_test.go (2 hunks)
• foundation/application_test.go (1 hunks)

• database/gorm/test_utils_test.go

database/console/migrate_reset_command_test.go (4)

7-7: Approval: Good addition of the require package

The addition of the require package from testify is a positive change. It allows for stricter assertions that will cause immediate test failure on error, leading to more robust and clear test cases.

---

51-55: Approval: Improved PostgreSQL test setup

The changes to the PostgreSQL setup function are excellent. The use of gorm.NewTestQuery(docker.Postgres()) simplifies the test setup process. The error handling with require.NoError(t, err) is consistent with best practices, providing clear and immediate failure messages if an error occurs.

The updated retrieval of the query and mock config is also correct and consistent with the new setup method.

---

62-66: Approval: Consistent improvement in SQL Server test setup

The changes to the SQL Server setup function are consistent with the improvements made to the MySQL and PostgreSQL setups. The use of gorm.NewTestQuery(docker.Sqlserver()) simplifies the test setup process. The error handling with require.NoError(t, err) is correct and consistent with best practices.

The updated retrieval of the query and mock config is also correct and consistent with the new setup method. This consistency across different database setups improves the overall readability and maintainability of the test code.

---

74-78: Approval: Consistent improvement in SQLite test setup and overall file enhancements

The changes to the SQLite setup function are excellent and consistent with the improvements made to the other database setups. The use of gorm.NewTestQuery(docker.Sqlite()) simplifies the test setup process. The error handling with require.NoError(t, err) is correct and consistent with best practices.

Overall, this file has seen significant improvements:

1. Consistent use of gorm.NewTestQuery() across all database types, simplifying the setup process.
2. Uniform error handling using require.NoError(t, err), which provides clearer and more immediate failure messages.
3. Consistent retrieval of query and mock config objects across all database setups.

These changes enhance the readability, maintainability, and robustness of the test code. Great job on the refactoring!

database/console/migrate_status_command_test.go (4)

7-7: Approval: Good addition of the "require" package

The inclusion of the "require" package from testify is a positive change. It allows for stricter assertions in tests, which can lead to more robust and reliable test cases.

---

52-56: Approval: Improved PostgreSQL setup

The refactoring of the PostgreSQL setup is well done. It follows the same pattern as the MySQL setup, improving code consistency. The use of require.NoError(t, err) is a good practice for handling errors in tests.

---

64-68: Approval: Consistent improvement in SQL Server setup

The refactoring of the SQL Server setup maintains the consistency established with MySQL and PostgreSQL setups. The use of gorm.NewTestQuery(docker.Sqlserver()) and require.NoError(t, err) demonstrates a uniform approach to database setup and error handling across different database types.

---

76-80: Approval: Consistent improvement across all database setups

The refactoring of the SQLite setup completes the uniform approach to database initialization across all tested database types. This change, along with the previous ones, significantly improves the code's consistency and maintainability.

The use of gorm.NewTestQuery() for all database types (MySQL, PostgreSQL, SQL Server, and SQLite) centralizes the database setup logic, likely reducing code duplication and potential inconsistencies. The consistent use of require.NoError(t, err) for error handling is also a positive change, ensuring that tests fail immediately and clearly when setup issues occur.

These changes align well with the PR's objective of simplifying the database/gorm/test_utils.go file and enhancing the testing experience for the database package.

database/console/migrate_rollback_command_test.go (6)

7-7: Excellent addition of the require package.

The inclusion of "github.com/stretchr/testify/require" is a positive change. Using require assertions instead of assert in test setup can lead to more immediate test failures when preconditions aren't met, making it easier to identify and debug issues.

---

39-43: Improved MySQL test setup with NewTestQuery.

Great refactoring of the MySQL setup:

1. Using gorm.NewTestQuery(docker.Mysql()) simplifies the setup process.
2. require.NoError(t, err) ensures immediate test failure on setup errors.
3. Assigning query and mockConfig from the NewTestQuery result improves code clarity.

These changes enhance maintainability and consistency across different database setups.

---

52-56: Consistent refactoring for PostgreSQL setup.

Excellent work on maintaining consistency:

1. The PostgreSQL setup now mirrors the MySQL setup, using gorm.NewTestQuery(docker.Postgres()).
2. Error handling and assignment of query and mockConfig follow the same pattern.

This consistency across database types significantly improves code maintainability and readability.

---

64-68: Consistent refactoring extended to SQL Server setup.

Excellent continuation of the refactoring pattern:

1. SQL Server setup now uses gorm.NewTestQuery(docker.Sqlserver()).
2. Error handling and variable assignments remain consistent with other database setups.

This consistent approach across all database types significantly reduces cognitive load when reading and maintaining the test code.

---

75-79: Comprehensive refactoring completed with SQLite setup.

Excellent work on maintaining consistency throughout:

1. SQLite setup now uses gorm.NewTestQuery(docker.Sqlite()).
2. Error handling and variable assignments remain consistent with all other database setups.

This completes a comprehensive refactoring across all database types. The consistent approach significantly improves code maintainability, readability, and reduces the potential for errors in test setups.

---

Line range hint 1-114: Excellent refactoring of database setup in tests.

The changes in this file represent a significant improvement in the test setup process:

1. Consistent use of gorm.NewTestQuery() across all database types (MySQL, PostgreSQL, SQL Server, SQLite).
2. Improved error handling with require.NoError().
3. Simplified and more readable code for query and mock configuration setup.

These changes align perfectly with the PR objectives of simplifying the testing experience and enhancing the overall quality of the test suite. The consistent approach across different database types will make future maintenance and additions easier.

Great job on this refactoring effort!

database/migration/schema_test.go (1)

39-41: Excellent refactoring of the database setup logic!

The changes in the SetupSuite method significantly improve the initialization process for the PostgreSQL Docker instance:

1. The code is more concise and readable.
2. Error handling is improved by using s.Require().NoError(err), which is more appropriate for test suites.
3. The use of gorm.NewTestQuery aligns with the PR objective of simplifying the database setup for tests.
4. These changes contribute to preparing for the removal of Wire, as mentioned in the PR objectives.

The implementation is consistent with the overall goal of simplifying the database/gorm/test_utils.go file and enhancing the testing experience for the database package.

Also applies to: 45-46

database/console/migrate_fresh_command_test.go (4)

7-7: Improved test assertions with require package

The addition of the require package from testify is a good practice. It provides more informative error messages and stops test execution immediately on failure, which can help in identifying issues more quickly during testing.

---

39-43: Improved SQLite test setup with better error handling

The changes to the SQLite setup function represent a significant improvement:

1. Using gorm.NewTestQuery(docker.Sqlite()) simplifies the database initialization process.
2. The error handling has been enhanced with require.NoError, which will cause the test to fail immediately if there's an issue setting up the database.
3. The new approach of obtaining the query and mock configuration from the TestQuery object is more streamlined and less error-prone.

These changes should make the tests more robust and easier to maintain.

---

63-67: Improved Postgres test setup

The changes to the Postgres setup function are consistent with the improvements made to other database setups. The use of gorm.NewTestQuery simplifies the initialization process, and the error handling with require.NoError is correct and consistent with best practices.

These changes contribute to a more uniform and robust testing approach across different database types.

---

75-79: Improved SQL Server test setup and overall consistency

The changes to the SQL Server setup function complete the consistent improvement across all database types in this test file. Key points:

1. Use of gorm.NewTestQuery simplifies database initialization.
2. Consistent error handling with require.NoError.
3. Streamlined approach to obtaining query and mock configuration.

These changes collectively enhance the test suite by:

• Simplifying the setup process for each database type.
• Improving error handling and test reliability.
• Increasing consistency across different database setups.

The refactoring aligns well with the PR objective of simplifying the database package testing experience.

database/console/migrate_refresh_command_test.go (5)

7-7: LGTM: Addition of require package

The addition of the require package from testify is a good improvement. It allows for more concise error handling in tests and aligns with the changes made in the setup functions.

---

38-42: LGTM: Improved SQLite setup function

The refactoring of the SQLite setup function is a good improvement:

1. Using gorm.NewTestQuery provides a more abstracted and potentially reusable approach to setting up test queries.
2. The switch to require.NoError offers more concise error handling.
3. Separating the query and config setup improves clarity and maintainability.

These changes align well with the PR objectives of simplifying the testing experience for the database package.

---

60-64: LGTM: Consistent Postgres setup function

The refactoring of the Postgres setup function is well done and consistent with the improvements made to the SQLite setup. The use of gorm.NewTestQuery and require.NoError maintains a uniform approach across different database types, which enhances maintainability and readability of the test suite.

---

71-75: LGTM: Consistent SQL Server setup and overall improvements

The refactoring of the SQL Server setup function maintains the consistency established in the previous database setups. This uniformity across all database types (SQLite, MySQL, Postgres, and SQL Server) is commendable and aligns well with the PR objectives.

Overall improvements observed:

1. Consistent use of gorm.NewTestQuery for all database types.
2. Uniform error handling with require.NoError.
3. Clear separation of query and config setup.

These changes contribute to a more maintainable, readable, and efficient test suite for the database package.

---

Line range hint 1-150: Overall assessment: Excellent refactoring with minor consistency suggestion

The changes made to this file significantly improve the testing setup for different database types. Key improvements include:

1. Consistent use of gorm.NewTestQuery across all database types.
2. More concise error handling using require.NoError (except for MySQL setup).
3. Clear separation of query and config setup.

These changes align well with the PR objectives of simplifying the testing experience for the database package and enhancing maintainability.

Suggestion for further improvement:

• Ensure consistency in error handling by using require.NoError(t, err) in the MySQL setup function, similar to other database setups.

Great job on this refactoring!

database/console/migrate_command_test.go (5)

7-7: LGTM: Addition of require package

The addition of the require package from testify is a good change. It allows for more concise and expressive error checking in the test cases, which aligns well with the refactoring done in the test setup.

---

46-50: Excellent refactoring of SQLite setup

The changes to the SQLite setup process are a significant improvement:

1. Using gorm.NewTestQuery simplifies the database initialization.
2. The switch to require.NoError for error handling is more concise and fail-fast.
3. Retrieving the mock configuration from the query object ensures consistency with the new setup method.

These changes enhance readability and maintainability of the test setup.

---

57-61: Consistent improvement in MySQL setup

The changes to the MySQL setup mirror those made for SQLite, which is excellent:

1. The use of gorm.NewTestQuery maintains consistency across database types.
2. Error handling with require.NoError is appropriately implemented.
3. The mock configuration retrieval is consistent with the new pattern.

This consistency across different database setups improves the overall structure and readability of the test suite.

---

81-85: Consistent improvement in SQL Server setup

The changes to the SQL Server setup are well-implemented and consistent with the improvements made to other database types:

1. The use of gorm.NewTestQuery simplifies the database initialization.
2. Error handling with require.NoError is correctly implemented.
3. The mock configuration retrieval follows the new pattern consistently.

This consistency across all database setups, including SQL Server, significantly improves the overall structure and maintainability of the test suite.

---

Line range hint 1-185: Overall excellent refactoring with minor improvement needed

The changes made to this file significantly improve the test suite for the MigrateCommand:

1. The introduction of gorm.NewTestQuery simplifies and standardizes the database setup process across all supported database types.
2. The use of require.NoError for error handling (except in one instance) improves the fail-fast behavior of the tests.
3. The consistent approach to retrieving mock configurations enhances the overall structure of the test suite.

These improvements align well with the PR objectives of simplifying the testing experience for the database package. They make the tests more readable, maintainable, and consistent.

There's one minor inconsistency in the Postgres setup (use of assert.Nil instead of require.NoError) that should be addressed for complete consistency.

Overall, this refactoring is a significant step forward in improving the testing framework for the database package.

database/factory_test.go (1)

82-83: LGTM: Simplified test suite setup

The changes to TestFactoryTestSuite function improve the code by simplifying the test setup. Moving the database initialization to a separate method (SetupSuite) is a good practice as it separates concerns and improves readability.

database/orm_test.go (4)

38-42: Improved consistency in OrmSuite struct fields

The renaming of sqlserverDB to sqlserverQuery and the consistent use of the Query suffix for all database-related fields enhance clarity and maintain consistency across the struct. This change aligns well with the contractsorm.Query type and improves code readability.

---

85-85: Consistent renaming in SetupTest method

The change from sqlserverDB to sqlserverQuery in the queries map is consistent with the earlier renaming in the OrmSuite struct. This ensures that the SetupTest method correctly uses the updated field name, maintaining consistency throughout the test suite.

---

50-51: Simplified TestOrmSuite function

The TestOrmSuite function has been streamlined, improving readability and maintainability. This change is beneficial as it separates concerns and likely moves the setup logic to a more appropriate location.

Please ensure that the removed Docker setup logic has been properly relocated, possibly to the SetupSuite method. Run the following script to verify:

---

90-92: Addition of TearDownSuite method for cleanup

The introduction of the TearDownSuite method is a good practice for ensuring proper cleanup after test execution. Removing the "goravel" file helps reset the test environment between runs.

However, could you please provide more context on the purpose and content of the "goravel" file? This information would help in understanding the full scope of the cleanup process and ensure that all necessary cleanup steps are included.

To better understand the usage of the "goravel" file, please run the following command:

✅ Verification successful

Verified TearDownSuite Cleanup

The TearDownSuite method effectively removes the "goravel" file, which is used exclusively within test files. This ensures that the test environment is properly reset after each run, adhering to best practices for test cleanup.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Search for references to the "goravel" file in the codebase

# Test: Find all occurrences of "goravel" file creation or usage
rg --type go '"goravel"'

Length of output: 8375

database/gorm/to_sql_test.go (2)

23-24: Excellent simplification of the test suite setup.

The changes in the TestToSqlTestSuite function align well with the PR objectives. By removing the Docker-related setup and error handling, the code becomes more concise and easier to maintain. This simplification is a positive step towards improving the testing experience for the database package.

---

Line range hint 1-238: Overall, excellent improvements to the test suite setup.

The changes in this file successfully achieve the PR objectives of simplifying the testing experience for the database package. By centralizing the database setup in the SetupSuite method and removing Docker-related code, the test suite becomes more maintainable and easier to understand. These improvements will likely make it easier to add and modify tests in the future, contributing to the overall quality of the codebase.

foundation/application_test.go (1)

308-309: Improved MySQL test configuration setup

The changes simplify the initialization of mysqlDocker by using supportdocker.Mysql() directly. This approach removes the dependency on the gorm package for this test, making it more straightforward and potentially easier to maintain. The modification aligns well with the PR objective of simplifying the database package testing.

database/gorm/test_utils.go (5)

77-80: Check for Errors After Initializing Query

There is an assignment to err but no immediate error handling after InitializeQuery.

Ensure that errors from InitializeQuery are properly handled to prevent unexpected behaviors.

---

101-101: Check for Go Version Compatibility with slices.Contains

The use of slices.Contains requires Go 1.21.

Refer to the previous comment regarding Go version compatibility.

---

123-126: Ensure Consistent Use of Context in QueryOfReadWrite

When initializing a new query with InitializeQuery, ensure that the context used is properly managed.

Confirm that using testContext is appropriate here and that it is properly initialized.

---

423-444: Missing Default Case Handling in newTestTables

In the newTestTables function and its methods, ensure that all cases for orm.Driver are handled.

Check that the default case returns an appropriate value or error if an unknown driver is passed.

---

31-31: Ensure testContext Is Properly Initialized Before Use

testContext is used in InitializeQuery but is not initialized.

Refer to earlier comment regarding initializing testContext.

Also applies to: 83-83

database/gorm/query_test.go (2)

12-12: LGTM!

The require package is a good addition for more concise and readable assertions in tests.

---

42-43: LGTM!

Using suite.Run is the recommended way to run test suites with testify.

Files that changed from the base of the PR and between 4486c1a and 97bb352.

• database/console/migrate_command_test.go (1 hunks)
• database/console/migrate_fresh_command_test.go (1 hunks)
• database/console/migrate_refresh_command_test.go (1 hunks)
• database/console/migrate_reset_command_test.go (1 hunks)
• database/console/migrate_rollback_command_test.go (1 hunks)
• database/console/migrate_status_command_test.go (1 hunks)
• database/factory_test.go (1 hunks)
• database/gorm/test_models.go (2 hunks)
• database/gorm/test_utils.go (12 hunks)
• database/gorm/to_sql_test.go (1 hunks)
• database/migration/schema_test.go (1 hunks)
• database/orm_test.go (2 hunks)

• database/console/migrate_command_test.go
• database/console/migrate_fresh_command_test.go
• database/console/migrate_refresh_command_test.go
• database/console/migrate_reset_command_test.go
• database/console/migrate_rollback_command_test.go
• database/console/migrate_status_command_test.go
• database/factory_test.go
• database/gorm/to_sql_test.go
• database/migration/schema_test.go
• database/orm_test.go

database/gorm/test_models.go (3)

349-349: Summary of database connection changes in test models.

These changes to the Connection() methods of Product and Box models appear to be part of the larger effort to simplify the database package testing, as mentioned in the PR objectives. The modifications align with the goal of streamlining the testing process for the database package.

However, to ensure these changes don't introduce any inconsistencies or breaks in the existing codebase, please:

1. Verify that all related tests have been updated to use the new connection types.
2. Ensure that any code relying on these models' connection types has been appropriately modified.
3. Consider adding a comment explaining the rationale behind these specific connection type choices for each model, if it's not obvious from the context.

Also applies to: 389-389

---

389-389: Verify the impact of changing the database connection for Box model.

The database connection for the Box model has been changed from "mysql" to "postgres". This modification might affect existing database operations and tests related to the Box model.

To ensure this change doesn't introduce unintended consequences, please run the following verification script:

Make sure to update any affected code or tests to accommodate this change.

---

349-349: Verify the impact of changing the database connection for Product model.

The database connection for the Product model has been changed from "postgres" to "sqlite". This modification might affect existing database operations and tests related to the Product model.

To ensure this change doesn't introduce unintended consequences, please run the following verification script:

Make sure to update any affected code or tests to accommodate this change.

database/gorm/test_utils.go (4)

15-50: Constants and types are well-defined.

The constants for test models and the TestTable enum-like type provide a clear structure for different testing scenarios. The TestReadWriteConfig struct is appropriately designed for configuring read/write tests.

---

Line range hint 1224-1229: Well-implemented mock pool configuration.

The mockPool function effectively sets up mock configurations for database connection pooling with reasonable default values. This ensures that the test environment accurately reflects the connection pooling behavior of the production environment.

---

Line range hint 1-1229: Comprehensive and well-structured database testing utilities.

This file provides a robust set of utilities for database testing across multiple drivers (MySQL, PostgreSQL, SQLite, and SQL Server). The implementation is flexible and covers various testing scenarios, including different configurations and table structures.

While the overall design is sound, there are several opportunities to reduce code duplication through refactoring, particularly in the mock implementations and table creation methods. Addressing these would further improve the maintainability of the code.

Despite these potential improvements, the current implementation successfully achieves its goal of providing a comprehensive testing framework for database operations.

---

220-302: Well-designed TestQuery structure and initialization.

The TestQuery struct and its initialization through NewTestQuery provide a flexible and comprehensive way to set up database tests for different drivers and configurations.

Ensure safe handling of variadic parameters in NewTestQuery.

In the NewTestQuery function, be cautious when accessing the withPrefixAndSingular variadic parameter. Consider adding a check for the length of the slice before accessing its elements to prevent potential index out of range errors.

Files that changed from the base of the PR and between 97bb352 and cb23431.

• database/console/migrate_command_test.go (2 hunks)
• database/console/migrate_fresh_command_test.go (2 hunks)
• database/console/migrate_refresh_command_test.go (2 hunks)
• database/console/migrate_reset_command_test.go (1 hunks)
• database/console/migrate_rollback_command_test.go (2 hunks)
• database/console/migrate_status_command_test.go (1 hunks)
• database/console/test_utils.go (1 hunks)
• database/factory_test.go (1 hunks)
• database/gorm/test_utils.go (12 hunks)
• database/gorm/to_sql_test.go (3 hunks)
• database/orm_test.go (6 hunks)
• support/docker/docker.go (1 hunks)
• support/docker/docker_test.go (1 hunks)

• database/console/migrate_fresh_command_test.go
• database/console/migrate_reset_command_test.go
• database/console/migrate_status_command_test.go
• database/factory_test.go

database/console/migrate_command_test.go (3)

10-10: LGTM: New import for mock console.

The addition of the mock console import is appropriate for the changes in the test function.

---

24-28: Excellent refactoring of test setup.

The use of gorm.NewTestQueries() and looping through different drivers significantly improves the test's maintainability and coverage. This change aligns well with the PR objective of simplifying the testing experience for the database package.

---

Line range hint 1-38: Overall excellent refactoring with minor suggestions for improvement.

The changes in this file significantly improve the test structure and maintainability. The use of gorm.NewTestQueries() and the loop through different drivers aligns perfectly with the PR objective of simplifying the testing experience. The test now covers multiple database types more efficiently.

To further enhance the code:

1. Consider using require.NoError() consistently for error handling throughout the test.
2. Ensure that the createMigrations() function (not shown in this diff) is updated to support all the database drivers being tested in the loop.

These minor adjustments will make the test even more robust and consistent with Go testing best practices.

database/console/migrate_rollback_command_test.go (1)

9-9: LGTM: New import for mock console.

The new import for the mock console package is correctly added and aliased. This import is used appropriately in the test function to create a mock context.

support/docker/docker_test.go (2)

71-71: Approved: Removal of redundant string conversion

The removal of the explicit string() conversion is a good change. Since test.name is already a string (as defined in the tests slice), this conversion was unnecessary. This change simplifies the code without altering its functionality, making it slightly more efficient and easier to read.

---

Line range hint 1-82: Overall assessment: Good improvement

This change, while minor, contributes positively to the code quality. It aligns with the PR's objective of simplifying and enhancing the testing experience. The removal of unnecessary type conversion makes the code cleaner and slightly more efficient. No other issues were observed in the file, and the overall structure and logic of the test function remain sound.

database/console/migrate_refresh_command_test.go (3)

9-9: LGTM: New import for mock console.

The addition of the mock console import aligns with the PR objective of improving the testing experience. This change suggests a more robust approach to testing console interactions.

---

18-22: Excellent refactoring of test setup.

The introduction of gorm.NewTestQueries() and the iteration over different database drivers significantly improves the test structure. This change:

1. Simplifies the test setup
2. Reduces code duplication
3. Improves maintainability
4. Provides a unified approach for all database types

This refactoring aligns perfectly with the PR objective of simplifying the database/gorm/test_utils.go file and enhancing the testing experience.

---

24-28: Good use of mock objects for improved test isolation.

The setup of mock objects for Artisan and Context, along with the creation of MigrateCommand using mockConfig, enhances the test's isolation and control. This approach:

1. Improves test reliability
2. Allows for more precise assertions
3. Follows best practices in unit testing

These changes contribute to a more robust testing framework, aligning with the PR's objectives.

support/docker/docker.go (3)

69-76: Excellent enhancement to database name handling!

The introduction of the newDatabase variable and the updated logic for SQLite database name construction are well-thought-out changes. They offer several benefits:

1. Improved flexibility in handling multiple database instances, especially for SQLite.
2. Maintained immutability of the original database parameter.
3. Consistent use of the potentially modified database name when creating the database driver.

These changes align well with the PR objectives of simplifying and enhancing the testing experience for the database package.

---

Line range hint 1-116: Overall approval: Well-implemented changes

The modifications to the Database function are focused, well-implemented, and align perfectly with the PR objectives. They enhance the flexibility of database handling in test environments without introducing unnecessary complexity or breaking existing interfaces. The implementation is clean, maintainable, and shows good consideration for different database types.

Great job on improving the testing framework for the database package!

---

69-76: Verify the impact on existing test cases

While the changes improve the flexibility of database handling, it's crucial to ensure they don't introduce unintended side effects.

Please run the following script to check for any existing test cases that might be affected by these changes:

If any test files are found, please review them to ensure they still work as expected with these changes.

database/console/test_utils.go (1)

1-7: LGTM: Package declaration and imports are appropriate.

The package name console is suitable for console-related utilities, and the imports are correctly aliased and relevant to the file's purpose.

database/orm_test.go (4)

30-31: LGTM: Improved test suite structure

The addition of the testQueries map in the OrmSuite struct is a good refactoring. It provides a more flexible and maintainable way to handle multiple database drivers in tests, replacing individual fields for each database type.

---

39-40: LGTM: Simplified test suite setup

The TestOrmSuite function has been streamlined to only run the OrmSuite. This simplification aligns well with the new approach of using gorm.NewTestQueries() and reduces complexity in the test setup, which is a good practice.

---

66-67: LGTM: Improved test coverage and maintainability

The changes in all test methods to iterate over the testQueries map instead of using predefined connections are excellent. This approach:

1. Makes the tests more dynamic and easier to maintain.
2. Ensures that all supported drivers are tested consistently.
3. Provides uniform changes across all test methods, which is good for consistency.

These improvements will make it easier to add or modify supported drivers in the future without having to update each test method individually.

Also applies to: 76-77, 95-96, 103-104, 115-117, 122-125, 133-134, 139-140, 151-152, 168-171, 178-181

---

Line range hint 1-241: Overall: Excellent refactoring of the ORM test suite

The changes made to this file significantly improve the structure and maintainability of the ORM test suite. Key improvements include:

1. Centralized setup of test queries for all supported drivers.
2. More flexible handling of different database drivers throughout the tests.
3. Consistent approach to iterating over supported drivers in all test methods.
4. Addition of proper teardown to clean up resources after tests.

These changes align well with the PR objectives of simplifying the testing experience and preparing for the removal of Wire. The new structure will make it easier to add or modify supported drivers in the future, enhancing the overall maintainability of the test suite.

database/gorm/test_utils.go (3)

26-41: Well-structured test table enumeration

The TestTable type and its associated constants provide a clear and type-safe way to represent different test tables. This approach enhances code readability and reduces the likelihood of errors when referencing specific tables in test scenarios.

---

181-190: Approve QueriesWithPrefixAndSingular and QueryOfAdditional methods

Both QueriesWithPrefixAndSingular and QueryOfAdditional methods are concise and serve specific purposes in the testing framework.

The QueriesWithPrefixAndSingular method provides a way to get queries with prefix and singular settings, which is useful for testing different naming conventions.

The QueryOfAdditional method creates an extra query on a separate Postgres instance, which can be valuable for testing scenarios that require an independent database.

These methods enhance the flexibility of the testing setup.

---

258-265: ⚠️ Potential issue

Improve error handling in CreateTable method

The CreateTable method effectively creates tables based on the provided TestTable types. However, there are a couple of points to consider:

1. Go version requirement: The use of slices.Contains requires Go 1.21+. Ensure that this requirement is documented in the project's README or go.mod file.

2. Error handling: The method currently panics if table creation fails. While this might be acceptable for some testing scenarios, it limits flexibility. Consider returning an error instead of panicking, allowing the caller to decide how to handle failures.

Here's a suggested improvement:

func (r *TestQuery) CreateTable(testTables ...TestTable) error {
    for table, sql := range newTestTables(r.docker.Driver()).All() {
        if len(testTables) == 0 || slices.Contains(testTables, table) {
            if _, err := r.query.Exec(sql()); err != nil {
                return fmt.Errorf("create table %v failed: %w", table, err)
            }
        }
    }
    return nil
}

This change allows for more flexible error handling in test setups.

#!/bin/bash
# Verify Go version requirement is documented
grep -q "requires Go 1.21" README.md || echo "Consider adding Go 1.21+ requirement to README.md"

database/gorm/to_sql_test.go (13)

23-24: Simplify test suite initialization is appropriate

The test suite now directly runs ToSqlTestSuite without unnecessary MySQL Docker setup, which simplifies the test initialization.

---

37-37: SQL assertions updated to PostgreSQL syntax

The SQL statements in the assertions have been correctly updated to use PostgreSQL syntax with positional parameters like $1, which is appropriate given the switch to PostgreSQL.

Also applies to: 40-40

---

46-46: Consistent use of PostgreSQL-specific SQL syntax

The INSERT statements now include the RETURNING "id" clause and use PostgreSQL parameter placeholders, ensuring consistency with the PostgreSQL dialect.

Also applies to: 49-50

---

59-59: Updated DELETE statements to match PostgreSQL syntax

The DELETE and soft delete statements have been updated with correct PostgreSQL syntax, using $1 placeholders and inlined parameters where appropriate, which ensures accurate testing of SQL generation.

Also applies to: 62-62, 66-67, 70-70

---

75-75: SELECT queries adjusted for PostgreSQL parameterization

The Find method tests now correctly use PostgreSQL parameter placeholders, enhancing the accuracy of the tests.

Also applies to: 78-78, 81-81, 84-84

---

89-89: Correct LIMIT clause usage in First method tests

The First method assertions now include the correct PostgreSQL LIMIT syntax with appropriate parameter placeholders.

Also applies to: 92-92

---

97-97: Verified ForceDelete method SQL statements

The ForceDelete method tests correctly reflect PostgreSQL syntax, ensuring that hard deletes generate the expected SQL.

Also applies to: 100-100, 103-103, 106-106

---

111-111: Get method SQL generation is accurate

The Get method tests now use PostgreSQL parameter placeholders, which aligns with the database dialect used in the tests.

Also applies to: 114-114

---

119-119: Adjusted Pluck method assertions for PostgreSQL

The Pluck method tests have been updated to use PostgreSQL syntax, ensuring the correctness of the generated SQL.

Also applies to: 122-122

---

127-127: Ensure proper handling of Save method SQL

The Save method tests correctly include the RETURNING "id" clause and use PostgreSQL parameter placeholders, which is appropriate.

Also applies to: 131-132

---

137-137: Sum method tests updated with correct SQL syntax

The SQL statements in the Sum method tests now correctly use PostgreSQL parameter placeholders, ensuring accurate SQL generation.

Also applies to: 140-140

---

145-145: Update method tests reflect accurate SQL

The Update method tests have been updated to generate SQL statements with correct PostgreSQL syntax, including parameter placeholders and updated field values.

Also applies to: 149-150

---

159-159: Consistent parameterization in complex Update method tests

The tests involving updating with a map and a struct have been adjusted to use PostgreSQL parameter placeholders, ensuring consistency and correctness.

Also applies to: 167-168, 171-171, 179-180