Issue: Standardize Tester Constructor Pattern Across Shared Library
Summary
The shared library tester registration and constructors have been updated to use a uniform no-argument pattern. All testers now follow the same construction approach with proper database initialization in their Prepare() methods.
Problem
The previous implementation had inconsistencies:
- Inconsistent constructor signatures: Some testers accepted optional config parameters (
*DBConfig, *MigrationTesterConfig), while others took no parameters
- Unused config fields: The
dbConfig field in DatabaseTester was never used - the database connection was always obtained from ApiTypes.PG_DB_Project in Prepare()
- Non-uniform pattern: Different testers used different initialization approaches, making the codebase harder to maintain
Solution
Standardized all shared library testers to follow a uniform no-argument constructor pattern:
- No-argument constructors: All testers now use
NewTesterName() with no parameters
- Proper DB initialization in Prepare(): Each tester's
Prepare() method obtains the database connection from ApiTypes.PG_DB_Project and verifies it
- Consistent pattern: All testers (shared and application-specific) now follow the same construction pattern
Files Changed
api/testers/registertesters.go
- Updated all factory calls to use no-argument pattern:
NewDatabaseTester() instead of NewDatabaseTester(nil)
NewMigrationTester() instead of NewMigrationTester(nil)
- Fixed documentation comment:
autotester.LoadTOMLPackages() instead of sharedtesters.LoadTOMLPackages()
api/testers/tester_database.go
- Removed
dbConfig *ApiTypes.DBConfig field from DatabaseTester struct (was unused)
- Changed
NewDatabaseTester(dbConfig *ApiTypes.DBConfig) to NewDatabaseTester()
Prepare() already properly initializes testDB from ApiTypes.PG_DB_Project
api/testers/tester-migration/tester_migration.go
- Changed
NewMigrationTester(cfg *MigrationTesterConfig) to NewMigrationTester()
- Constructor now always creates default config internally with
cfg.ApplyDefaults()
- Maintains same behavior but with cleaner API
Testing
- Build verified:
go build ./shared/go/... completes successfully
- All workspace modules build successfully:
shared/go/... ✓
tax/server/... ✓
ChenWeb/... ✓
Ory/backend/... ✓
Impact
- Improves: API consistency across all testers
- Simplifies: Tester registration - no need to pass nil or config parameters
- Removes: Unused
dbConfig field from DatabaseTester
- Aligns: Shared library testers with application-specific testers (tax project)
Related
Issue: Standardize Tester Constructor Pattern Across Shared Library
Summary
The shared library tester registration and constructors have been updated to use a uniform no-argument pattern. All testers now follow the same construction approach with proper database initialization in their
Prepare()methods.Problem
The previous implementation had inconsistencies:
*DBConfig,*MigrationTesterConfig), while others took no parametersdbConfigfield inDatabaseTesterwas never used - the database connection was always obtained fromApiTypes.PG_DB_ProjectinPrepare()Solution
Standardized all shared library testers to follow a uniform no-argument constructor pattern:
NewTesterName()with no parametersPrepare()method obtains the database connection fromApiTypes.PG_DB_Projectand verifies itFiles Changed
api/testers/registertesters.goNewDatabaseTester()instead ofNewDatabaseTester(nil)NewMigrationTester()instead ofNewMigrationTester(nil)autotester.LoadTOMLPackages()instead ofsharedtesters.LoadTOMLPackages()api/testers/tester_database.godbConfig *ApiTypes.DBConfigfield fromDatabaseTesterstruct (was unused)NewDatabaseTester(dbConfig *ApiTypes.DBConfig)toNewDatabaseTester()Prepare()already properly initializestestDBfromApiTypes.PG_DB_Projectapi/testers/tester-migration/tester_migration.goNewMigrationTester(cfg *MigrationTesterConfig)toNewMigrationTester()cfg.ApplyDefaults()Testing
go build ./shared/go/...completes successfullyshared/go/...✓tax/server/...✓ChenWeb/...✓Ory/backend/...✓Impact
dbConfigfield fromDatabaseTesterRelated