Architecture DSL
mihaeu opened this issue · comments
Quick draft:
<?php
beforeClass() {
// setup
$fileSet = $finder->find(__DIR__ . '/src')
->addAll($finder->find(__DIR__ . '/vendor'));
$dependencies = $staticAnalyser->analyse($fileSet);
// setup shorthand
analyse('path1', 'path2');
}
// test
test() {
$models = defineLayer()
->from('Some\Namespace\Bla')
->from('/special.*regex/');
$views = defineComponent()
->from('')
->from('');
$controllers
->dependsOn($models)
->but()
->mayNotDependOn($views);
$util
->mayNotHaveDependencies();
$views
->mayNotBeDependentOn();
package('Vendor/Namespace')
->mayNotDependOn()
->classesFromDir(__DIR__ . '/../vendor');
classesMatching('/.*Service.*/')
->mayOnlyDependOn()
->classesMatching('/.*Provider.*/');
}
Assertions using xUnit i.e. PHPUnit Framework Assertions.
Hi Michi,
Looks pretty nice.
Some notes:
dependsOn
: For consistencymayDependOn
- There doesn't seem to be any difference between Layer and Component and Package, you intend to add syntactic sugar for all these more or less equivalent notions?
Do you know how you will handle the errors? Since it does not make much sense to define a test for each layer restriction it would be great if all errors in one test are collected and returned in one report.
Best
Hannes
Thanks for the feedback @Merenptah
I finally got around to actually implement a first draft. Super ugly, but it's a start. Test cases aren't looking too bad: https://github.com/mihaeu/dephpend-tests/blob/master/tests/integration/ArchitectureTest.php
dependsOn: For consistency mayDependOn
+1
There doesn't seem to be any difference between Layer and Component and Package, you intend to add syntactic sugar for all these more or less equivalent notions?
Good question. I was thinking syntactic sugar doesn't hurt, on the other hand people complain when you remove it later on ... hmmm.
Do you know how you will handle the errors? Since it does not make much sense to define a test for each layer restriction it would be great if all errors in one test are collected and returned in one report.
Definitely. I was thinking of:
- may depend on
- nothing else
- may not depend on
- may not depend on anything
That would be for outgoing dependencies. Not sure yet what to do about incoming dependencies.
I added a basic MVC example at https://github.com/mihaeu/dephpend-tests with one violation. Implementation is a work in progress.
Generated using dephpend uml tests/examples/mvc --output=test.png
Test output should be something like:
- Class XYZ from (layer|module|component|package) ABC should not depend on Class IOP from (...) JKL
I will stop using issues for my personal feature requests because it makes the project look more broken than it is 😅