Skip to content

Conversation

@rh-amarin
Copy link
Contributor

This PR introduces an script for testing automatically:

  • cloning the app
  • generating a new entity

Why an script and not an integration tests?

  • Since integration tests run within containers, this integration was running containers within containers
  • I tried, and I managed to do it, but it was WAY more complex than the script
  • The script approach is easier to understand and use, since the execution within containers wasn't streaming logs, and the process was more opaque
  • Testing the generators is not that common, so this may only be required when changing something in clone command or template files

Truncating tables

When generating a new entity with the generator.go , the file pkg/db/db_session/testcontainer.go doesn't get updated.

This makes the tests fail since the tables are not cleaned after each test.

Since this ResetDB is only for testscontainers, it is safe to truncate all the tables but the migrations one.

This will allow us to auto

}
for _, table := range tableNames {
if err := g2.Exec(fmt.Sprintf("TRUNCATE TABLE %s CASCADE", table)).Error; err != nil {
glog.Errorf("Error truncating table %s: %s", table, err)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Truncating all tables by query (instead of a hard-coded list of table names) is a good improvement, but I wonder if it's needed at all?

The improved way of resetting between tests is to dump the database entirely and recreate it from a template. The template (template1, part of default postgres) gets all the migrations applied once, and then new DBs are restored from that template.

https://github.com/openshift-online/rh-trex/blob/main/pkg/db/db_session/test.go#L50

I think we might be able to remove table truncation entirely.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then, that mechanism is not properly working in the current tests, since it failed for me.

I will revisit this.

When using test containers, it also allows us to run tests in parallel.
Than means, one PostgreSQL instance per test
Or something in between, having a subset of tests sharing the same instance

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test containers are great. Restoring all those postgres instances from template1 is a significant performance improvement, especially when they number of migrations grows over time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is why I mentioned the "something in between"

Here is a somewhat crazy idea
Generate a testcontainer image with a PostgreSQL already migrated
After that, spinning up a new PostgreSQL is the same as creating instances from template1
And then we can use some parallelization for tests

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that sounds good, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants