Giter Club home page Giter Club logo

Comments (6)

rgomezcasas avatar rgomezcasas commented on August 22, 2024 2

I prefer the first 😬

from php-ddd-example.

JavierCane avatar JavierCane commented on August 22, 2024 1

@xabi93 was just asking to me how to implement integration test in his PR: #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 tests

However, 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.scala

We'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 infrastructure folders. 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 src folder structure and the test one. We can see this specially while taking a look at the stub folder. Now we would be understanding that these classes belong to the tests infrastructure.

What do you think?

from php-ddd-example.

JavierCane avatar JavierCane commented on August 22, 2024 1

I don't have a really strong opinion here, so… go ahead with the first approach then πŸ™‚

from php-ddd-example.

rgomezcasas avatar rgomezcasas commented on August 22, 2024 1

😬😬😬

from php-ddd-example.

x4b1 avatar x4b1 commented on August 22, 2024

I think having tests separately in another folder is cleaner, and making it easier to know where to add another test.
Now I have to add integration tests for the telegram notification and I don't know where I have to modify, but maybe this is my fault, not because of the project structure. 😞

from php-ddd-example.

JavierCane avatar JavierCane commented on August 22, 2024

Not at all @xabi93!

We're evaluating this change because the current tests structure is not clear enough. So it's completely understandable how it can frustrate anyone new to the project facing tasks as the one you're trying to do.

In the meantime, I had posted a comment in your PR (#29 (comment)) explaining how could you add this integration test in the current test structure. We'll move it with all the other test code when we take action on this issue, but this way you can continue with your PR without being blocked πŸ™‚

from php-ddd-example.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.