JavierCane
commented
6 years ago @xabi93 was just asking to me how to implement integration test in his PR: https://github.com/CodelyTV/cqrs-ddd-php-example/pull/29
One of the doubts was regarding the confusing folder structure, so maybe he's interested into this issue :P
Maybe we could define a test structure based on the one we've used for the https://github.com/CodelyTV/scala-http-api/ project:
$ tree scala-http-api/src/test/tv/codely/scala_http_api/module -L 5
.
├── IntegrationTestCase.scala
├── UnitTestCase.scala
├── shared
│ ├── domain <- Test infrastructure such as the application domain model stubs/object mother
│ │ ├── DateTimeStub.scala
│ │ ├── DurationStub.scala
│ │ ├── IntStub.scala
│ │ ├── StringStub.scala
│ │ └── UuidStub.scala
│ └── infrastructure <- Mix of test infrastructure and actual integration test for the infrastructure application layer implementations
│ ├── MessagePublisherMock.scala
│ ├── logger
│ │ └── scala_logging
│ │ └── ScalaLoggingLoggerShould.scala <- ScalaLoggingLogger class integration test
│ └── message_broker
│ └── rabbitmq
│ ├── MessageConsumer.scala <- Infrastructure needed for the integration test
│ ├── MessagePurger.scala <- Infrastructure needed for the integration test
│ ├── RabbitMqMessageConsumer.scala <- Infrastructure needed for the integration test
│ ├── RabbitMqMessagePublisherShould.scala <- RabbitMqMessagePublisher class integration test
│ └── RabbitMqMessagePurger.scala <- Infrastructure needed for the integration test
└── video
├── VideoIntegrationTestCase.scala
├── application
│ ├── create
│ │ └── VideoCreatorShould.scala <- Use case unit test
│ └── search
│ └── VideosSearcherShould.scala <- Use case unit test
├── domain <- Test infrastructure such as the application domain model stubs/object mother
│ ├── SeqStub.scala
│ ├── VideoCategoryStub.scala
│ ├── VideoCreatedStub.scala
│ ├── VideoDurationStub.scala
│ ├── VideoIdStub.scala
│ ├── VideoStub.scala
│ └── VideoTitleStub.scala
└── infrastructure <- Mix of test infrastructure and actual integration test for the infrastructure application layer implementations
├── marshaller
│ └── VideoJsValueMarshaller.scala <- Test infrastructure needed in order to avoid using the production marshaller and actually testing its behaviour
└── repository
├── DoobieMySqlVideoRepositoryShould.scala <- DoobieMySqlVideoRepository class integration test
└── VideoRepositoryMock.scala <- Test infrastructure needed in order to do not use production implementations in unit testsHowever, I'm not 100% confident about it. So I'm not sure if we would have to replicate it in this project, or iterate it a little bit. Here you have an alternative I would take into account before refactoring:
$ tree scala-http-api/src/test/tv/codely/scala_http_api/module -L 5
.
├── shared
│ ├── infrastructure
│ │ ├── IntegrationTestCase.scala
│ │ ├── UnitTestCase.scala
│ │ ├── message_broker
│ │ │ ├── MessagePublisherMock.scala
│ │ │ └── rabbitmq
│ │ │ ├── MessageConsumer.scala
│ │ │ ├── MessagePurger.scala
│ │ │ ├── RabbitMqMessageConsumer.scala
│ │ │ └── RabbitMqMessagePurger.scala
│ │ └── stub
│ │ ├── DateTimeStub.scala
│ │ ├── DurationStub.scala
│ │ ├── IntStub.scala
│ │ ├── StringStub.scala
│ │ └── UuidStub.scala
│ └── integration
│ ├── logger
│ │ └── ScalaLoggingLoggerShould.scala
│ └── message_broker
│ └── RabbitMqMessagePublisherShould.scala
└── video
├── infrastructure <- Only test infrastructure
│ ├── VideoIntegrationTestCase.scala
│ ├── marshaller
│ │ └── VideoJsValueMarshaller.scala
│ ├── repository
│ │ └── VideoRepositoryMock.scala
│ └── stub <- Stubs/Object mother also understood as test infrastructure
│ ├── SeqStub.scala
│ ├── VideoCategoryStub.scala
│ ├── VideoCreatedStub.scala
│ ├── VideoDurationStub.scala
│ ├── VideoIdStub.scala
│ ├── VideoStub.scala
│ └── VideoTitleStub.scala
├── integration <- Only integration tests
│ └── repository
│ └── DoobieMySqlVideoRepositoryShould.scala
└── unit <- Only unit tests
├── VideoCreatorShould.scala
└── VideosSearcherShould.scalaWe've discussed sometimes about this, and I'm neither 100% sure about this second approach, however, there are some pros that I really like despite the cons:
Pros:
- We don't mix different kind of things in the
infrastructurefolders. Now we would be separating what we understand as classes only intended for testing (test infrastructure), and classes actually testing the behavior of the infrastructure layer in the production code (integration tests).
Cons:
- We do lose the previous similarities between the
srcfolder structure and thetestone. We can see this specially while taking a look at thestubfolder. Now we would be understanding that these classes belong to the tests infrastructure.
What do you think?
rgomezcasas
x4b1
To a parallel
testfolder making it easier to find the test you're looking for