Implement haveNameEndingWith / haveNameNotEndingWith

[stefluhh]

When I was using the framework I wanted to make sure, that EventHandlers in our project are always called *EventHandler. Since no such method "endsWith" exists, I had to use a regex for that. I don't like that too much, so I thought I use the chance for my very first OpenSource contribution and here it is :)

For some reason 9 Unit tests are failing, however they also fail without my changes.

[codecholeric]

Thanks a lot for your PR 😃

Originally I thought about it, and I feared the complexity (okay, it was lazyness 😉). Since if we add should().haveNameEndingWith(..), it would be consistent, to also have that().haveNameEndingWith(..). And certainly somebody might ask "why endsWith, but not startsWith?".
But on the other hand, the user should be the main focus, and you're right, from an user's point of view, it is nicer, to directly express your intention, instead of writing sth. like matching(".*Suffix").

However, I'm wondering, if it is really "name ends with", that we want. I have had this use case as well (and used regex 😉), and what I wanted to assert, was the simple name. As far as I understand, it's the same for your case. Usually this would be kind of irrelevant, but when the 'symmetric' startsWith is requested (which I could well imagine), I doubt, that anybody wants a startsWith for the fully qualified class name. Thus I would propose, to change your PR, to check against the simple name, what do you think? I have raised an issue for that -> #41

You don't have to implement the full issue of course, I'm happy, to merge the should-part as it is, and add the rest with further PRs (which I or someone else could do as well)
One thing I have noticed, is that there is an inconsistency between should().haveNameEndingWith(..) and ArchConditions#haveNameEndsWith(..). I think it should be ArchConditions#haveNameEndingWith(..) to be consistent with the rest of the conditions.
What do you think, is that okay for you, to

• refer to JavaClass#simpleName instead of JavaClass#name
• rename ArchConditions#haveNameEndsWith(..) consistently
• aggree to the ArchUnit Contributor License Agreement 😉 ?

[codecholeric]

PS: I don't know about the unit tests, since the Travis CI build seems to run successfully? Hope that's not an inconsistency between your local build and the CI build (I hoped the Gradle Wrapper would minimize those dangers).
Anyway, if it continues, you could run the Gradle build with ./gradlew build -P scanBuild and post the link to your build scan...

[stefluhh]

Hi,

originally I also thought to implement startingWith and then noticed that it would match against the package name instead of the classname, since I was using name() instead of simpleName(). I think you are right with the hint that it would be better to rename the whole method to simpleClassNameEndingWith, I just didn't think about it.

Regarding the endsWith, on my first draft I wanted to have it like this, but then failed with some UnitTests (RandomRuleTest), that on first sight seemed to check my method signatures against the descripting text. When I thought more about the English text I came to the conclusion that it must be either have name ending with or having name end with and decided for the first to be consistent with the other haves.

[stefluhh]

I hereby agree to the terms of the ArchUnit Contributor License Agreement. ;-)

[codecholeric]

Thanks a lot for your contribution and adjusting this, I'm gonna merge it now 😃
However, I'll probably remove AndSimpleName, and make everything apply directly to JavaClass. I had thought about this in the past (exactly HasName.AndSimpleName 😉), but chose against it, since I can't think of anything besides JavaClass that would ever implement this (and normally I don't introduce interfaces as abstractions, if I can't think of at least two things, that share this commonality...)
If I'll ever see anything besides JavaClass, that has a 'simple name', I'll reintroduce it 😉

[stefluhh]

Hi @codecholeric
I was implementing that method first on HasName and then struggled with myself because I had to implement that method then also on JavaMember and JavaField (or something) and then reverted my changes and implemented it like AndFullname.

Thanks for merging, when I have time I will contribute again. I see lots of potential in your framework, thanks for the great job.