I'm not sure the proper way to handle this. If I add @aws-cdk/aws-pipes-targets-alphs to devDependencies, it creates a circular dependency. is eslint-disable-next-line import/no-extraneous-dependencies OK to have here?

@moelasmar I may need your input here. Do I need to go back to those TestClasses?

sorry @msambol I missed checking this PR, I will take a look to it tomorrow.

Thanks! The build is failing but those look like good imports to me in the integration test?

@aws-cdk/aws-pipes-sources-alpha: /codebuild/output/src3454251283/src/github.com/aws/aws-cdk/packages/@aws-cdk/aws-pipes-sources-alpha/test/integ.dynamodb.ts
@aws-cdk/aws-pipes-sources-alpha:   3:27  error  Unable to resolve path to module '@aws-cdk/aws-pipes-targets-alpha'  import/no-unresolved
@aws-cdk/aws-pipes-sources-alpha: /codebuild/output/src3454251283/src/github.com/aws/aws-cdk/packages/@aws-cdk/aws-pipes-sources-alpha/test/integ.kinesis.ts
@aws-cdk/aws-pipes-sources-alpha:   3:27  error  Unable to resolve path to module '@aws-cdk/aws-pipes-targets-alpha'  import/no-unresolved
@aws-cdk/aws-pipes-sources-alpha: /codebuild/output/src3454251283/src/github.com/aws/aws-cdk/packages/@aws-cdk/aws-pipes-sources-alpha/test/integ.sqs.ts
@aws-cdk/aws-pipes-sources-alpha:   4:27  error  Unable to resolve path to module '@aws-cdk/aws-pipes-targets-alpha'  import/no-unresolved
@aws-cdk/aws-pipes-sources-alpha: ✖ 3 problems (3 errors, 0 warnings)

@moelasmar Wondering if I should revert some of these changes and do one test-classes.ts file that contains an SqsSource in the targets directory and an SqsTarget in the sources directory, that way there are no dependencies between the two.

sorry @msambol for the late response. It appears I initially overlooked the splitting of this service into the main module and the source and target modules that depend on it.

I now understand why we avoided using actual resources or targets in the integ test cases. I agree with your suggestion to include the test-classes.ts file in both the source and target modules.

Could you also add a comment to clarify why we’ve taken this approach, along with a note suggesting we revisit this once we graduate these modules?"

@moelasmar The more I look at this, I prefer to leave the TestTarget in the integration file. I would like to close this PR in favor of #31980. I will then make similar changes in pipes-targets so it is consistent.

I was thinking that you will move the TestTarget to the test-classes.ts that already exist in the testing directory, and keep using it instead of the real SqsTarget or any other real Targets.

Also, just add a comment on it for why we choose this direction.

@moelasmar I made the change locally, but it didn't feel right to me. I would need to put two different implementations in that file, since one has an input transformation. And the current class in test-classes.ts is used for unit tests. I think I prefer to keep all the code for individual integration tests in one file...