Comments & Discussion
I’m starting a rewrite/redesign of my app which handles event, student, ensemble, and library management for tecachers and chorl organizations. I’ve loosely incorporated modules and DDD into the current version but this course helped me put a more complete framework around the costs and benefits of each approach. My biggest take-away is from the first lesson: PLANNING, and asking the question “What value am i getting from implementing this-or-that design pattern. well done, as usual, Povilas!
Hi Povilas, how do you approach writing tests for Laravel + DDD projects?
Normally, when I write tests for a standard Laravel project, all the tests are basically feature tests, largely because I don't feel that writing unit tests is really necessary in most cases.
But after watching the course, I realized that when using the DDD approach, we really do need to write unit tests as well.
What do you think?
Unit tests are great, if you want to specifically test the functionality of one of your features.
For example, you have an "invoice service" which accepts Items and calculates various amounts (subtotal, total, VAT, discount and so on). In this case, writing Unit test for these calculations - are more beneficial than Feature test. You don't go and create a full invoice, you just pass the data and get an outcome back to check. This is great if your app has a bunch of services like that and you need to make sure that they work as expected.
Now, from this we can look at DDD - there is a lot of smaller Domain services/classes, which we can test individually. With this, we can have the following:
- Tested individual service
- Tested service interaction with each other
- Tested feature
It simply adds more layers, and honestly - at some point this just becomes easier to work with! If one service breaks, your unit tests (given that you write a test for that case) will tell you exactly where the mistake is.
On top of all that, high test coverage Unit tests just give you a piece of mind that if you pass 5, and 4 to a sum($a, $b) - you will always get 9 back. If that does not happen, then you know which method in your feature is broken :)
Well, that was an excellent course! All of Povilas's comments were very relevant, and I learned a lot thanks to this course! I appreciated both parts: The university example is well-suited, and the modules packages are well-explained! The implementation of Domain-Driven Design is really very good and truly illustrates the complexity of such an approach. Thank you very much!