Package/Service Testing

Hello, community,

I am very new to TDD, but I am definitely taking it by the bull's horns and getting it done. There is something I am not clear on, and after a couple of days, still not any closer to this answer... Perhaps someone here can guide me to the right direction.

I am building a large application, and I decided to develop it by extracting major features into their own package, so that the code base is managed. Each package has a duty to do etc.

However, I am stuck on how to properly write tests for the packages, in the packages, because the packages require some core elements of the laravel app, as well as other packages, but do not necessarily need these packages to function.

Here is an example:

User (Lives in main Laravel App)
Product (Package)
Attributes (Package)

So a user can create a product. When this product is created, the observer then looks for the relationship "attributes" and if exists, calls a method and generates the pre-defined attributes... Everything works if directly developed into the app. But now, as I split into packages, what is the proper way to write the tests?

martinbean

4 years ago

Best Answer

Level 80

I am building a large application, and I decided to develop it by extracting major features into their own package, so that the code base is managed. Each package has a duty to do etc.

@zhxscript If you thought developing a large application was going to be difficult, you’ve just made things even more difficult for yourself by extracting things to packages, as now not only do you have to coordinate the development of the application itself, but you also have to coordinate the publishing and pulling of packages.

You’d be better off just setting and sticking to a directory structure in your application yourself inside of extracting things to packages. As you’ve found, it makes things like testing more difficult, because now every package needs an instance of the Laravel framework itself to test integration, which just isn’t efficient at all.

If you’re not a fan of Laravel grouping classes by topic (i.e. controllers, events, jobs, etc) then you might consider a more “modular” structure where you define modules for things like blog, shop, etc. So like “packages”, but the classes remain in your application’s codebase and you’re not having to mess about with package versioning, publishing, and pulling of these packages just to build an application.

zhxscript

4 years ago

Level 2

@martinbean - Thanks for the response...

Your suggestion of modular structure, but staying in the codebase is exactly what I decided to do, it makes a lot of sense, and will simplify things surely in writing tests and overall development experience.

Essentially, within my project root, I added a custom folder called "services" and in there will lie all my "packages" that I can require/remove from the main apps composer file, based on the required configuration of the application.

1 like

martinbean

4 years ago

Level 80

Essentially, within my project root, I added a custom folder called "services" and in there will lie all my "packages" that I can require/remove from the main apps composer file, based on the required configuration of the application.

@zhxscript That doesn’t really sound like you’re solving anything though. You’re still having to update your Composer file, and still having to run composer update when you need to add or remove a “package”.

Just keep things simple. All you need to do is define a namespace and put your code there:

"autoload": {
    "psr-4": {
        "App\\": "app/",
        "Database\Factories\\": "database/factories/",
        "Database\Seeders\\": "database/seeders/",
        "YourVendorName\\": "src/"
    }
}

There you go. You can now put all of your classes in a src directory and have your class namespaces begin with YourVendorName. So a class named Bar in src/Foo/Bar.php will have the namespace YourVendorName\Foo. No need for constantly tinkering with your Composer file any more. You can add sub-namespaces as and when you need to.

Please or to participate in this conversation.