Level 80
@bernhardh You should be running Dusk from inside your package. Its tests shouldn’t be ran from the consuming application.
Mar 15, 2021
11
Level 1
Dusk tests inside my package folder
Hello,
is there a way, to add additional folders for testing in laravel dusk?
I tried to add it in the Unit test section of phpunit.xml
<testsuite name="Unit">
<directory suffix="Test.php">./tests/Unit</directory>
<directory suffix="Test.php">./packages/MyPackage/tests</directory>
</testsuite>
but this doesn't work.
Level 1
I am writing code in a domain driven manner, so I organised a lot of logic inside packages. Now I have >30 packages, so running tests in each folder isn't a real solution.
Level 80
I’m not sure what this has to do with domain-driven design? DDD is about organising your entities and business logic by domain. It doesn’t mean carve your codebase into arbitrary modules/packages.
I’m guessing you have things like controllers in your “packages” too? If so then that’s wrong, as controllers should live in an “Application” layer. Your controllers (and Artisan CLI commands) are entry points to your application’s domains; not part of domains themselves.
Level 1
Short answer: Thanks for your reply and your effort, but that is irelevant to the question. The question is - can I run tests of multiple packages at once.
Long answer: A module or package would be an aggregate (see https://nicolaswidart.com/blog/writing-modular-applications-with-laravel-modules). So instead of spread code (views, logic, etc.) over a couple of folders and subfolders, I wrap it inside a package. I love laravel, but hate it, that it doesn't have a build in module system. If you are working on a specific topic - for example a contact form - you will have to navigate to the controller in app/Http/Controllers/ContactFormController.php, then jump around in the filesystem and go to view in resources/views/contactform.blade.php and if you now need something else like Forms, Models, Listeners, etc. you will have to jump around in dozens of other folders spread all around over. If you group it in a module, you have a folder ContactForm where everything you need is located.
Level 80
but hate it, that it doesn't have a build in module system
@bernhardh Because not every one uses “modules”, so it would be unfair of the framework to enforce that “pattern” on every one.
f you are working on a specific topic - for example a contact form - you will have to navigate to the controller in app/Http/Controllers/ContactFormController.php, then jump around in the filesystem and go to view in resources/views/contactform.blade.php and if you now need something else like Forms, Models, Listeners, etc. you will have to jump around in dozens of other folders spread all around over. If you group it in a module, you have a folder ContactForm where everything you need is located.
I don’t know about you, but I have a text editor that lets me easily find files using a palette, rather than having to manually traverse directories and files.
If you’re interested in actual domain-driven design, and not just stuffing code into arbitrary “modules”, then I’d suggest reading the book that introduces the topic:
https://www.amazon.co.uk/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/
Level 1
It's ok, that you don't like this concept. Omnes viae Romam ducunt. But I don't understand why are you investing time and reply to a question with completly off topic stuff in such an arrogant way.
You are calling it "wrong". Ok. So dozens of other frameworks (for example fuelphp) and this package (https://github.com/nWidart/laravel-modules) for laravel with "just" 3.5k stars does it "wrong" as well.
@bernhardh Because not every one uses “modules”, so it would be unfair of the framework to enforce that “pattern” on every one.
Thats not a good argument. First of all - currently the framework enforces NOT to use this pattern (without sarcastic quotes). Is that better? No, its not. But more importantly - I would prefere this feature as optional. There is quite a lot of functionality optional and even doubled. For example Observer vs. static/anonymous functions in the boot method. But its ok for me, since I can go around with third party packages or implement it myself.
I don’t know about you, but I have a text editor that lets me easily find files using a palette, rather than having to manually traverse directories and files.
I don't need to find them, I have them all in one place.
To sum it up:
I normally like to discuss such topics, but not in this presumptuous way.
Level 61
I am writing code in a domain driven manner, so I organised a lot of logic inside packages.
I do the same thing.
Now I have >30 packages, so running tests in each folder isn't a real solution.
Point of packages is that they are self-tested bits of code that you can reuse. No need to test them every time. Like you're not running tests for the framework every time you run tests for your code.
Level 1
You are right, but I wanna test everything before I deploy code to production. But ok, if there is no option, then I will have to write a shell script or something.
Level 61
Let's say you have a structure like this:
home
+-- code
+-- app1
+-- package1
+-- package2
If you include your packages in the app1 project and you haven't changed anything from any of the packages folder, there is no reason why you should test packages again.
But inside of the app1 folder, you should write integration like tests that prove that all packages work well as whole/together.
So if you have individual tests for every package and integration tests for the whole app you are good to go.
Level 15
@bernhardh I'm in the same shoes. Did you find any solutions for your problem?
Level 1
@netdjw Sorry, no. I haven't found an solution.
Please or to participate in this conversation.