Level 102
Just to understand better.
- There is no testing in the packages?
- You need to know if the projects break on every save of a file instead of just before you commit the final code ?
Sep 28, 2022
8
Level 27
Automated testing and notification
Here's my "problem", looking for a solution :)
- Several of my projects rely on the same few packages
- These packages are directly symlinked
- The original intent is that, whenever I modify my packages, I taken into consideration all my projects' needs
- But I haven't been able to put together something real time
I'm aware of phpunit-watcher but not sure how to make it notify me when modifying packages breaks another project.. open to any suggestions. Thank you.
Level 27
Each package has its own tests, but sometimes projects break because of changes in function definitions
I would like it to be as soon as possible, but not on every save as some tests take longer... Usually 1 project takes under 2 mins.
Commits are a bit too late, because commits kind of means design already decided.
I'm open to hearing your process and reasoning.
Level 102
@laracoft Maybe you can write an npm script that you can start, that watches for changes in the package and runs the tests in the others? https://github.com/paulmillr/chokidar
Level 27
hmm, now that you mentioned it, I think the issue is the package doesn't know which project is using it. This could be my new problem definition
Is there a way to figure out who is symlinked to a particular folder?
Level 27
Ok, I think I figured it out
- I will build a map of my packages (many) and projects (a few) using them
- Once changes are detected in my packages, the respective projects will run
artisan test - Do you know of a way to send email reports if a test fails for
artisan test? (If not I will just google later)
Level 102
@laracoft I would probably look into getting phpunit to exit as an error when failing and send a mail based on that. You could catch this in a node script I'm sure :)
Level 27
Haha, ok, I'm actually not so familiar with bash scripts. Honestly, I would prefer a Laravel command that I can add to $schedule. Let me google. Thank you.
Level 27
In the end, this is what I settled on
- I separated the running of tests from the reporting of results
- A test ends with one of many results: passed, skipped, incomplete, risk, fail and exception
- Reporting frequency should be based on result to avoid spamming, yet keep an eye on not-so-critical stuff
- On top of that, Git changes are more useful when reported at a project level (not package level)
Please or to participate in this conversation.