https://kotlinlang.org logo
Join Slack
Powered by
hmm i thought about that, but it definately does n...
# atrium
c
hmm i thought about that, but it definately does not suggest values after typing ignoringCase
r
Hm... give me a moment, I'll check the docs
c
that works: `contains.ignoringCase.atLeast(1).values("HYPERLOCAL")`but without the 
atLeast(1)
it does not work
r
Yupp, as I said I was not 100% sure ;)
c
can’t you support both?
r
I could, I could also add 
containsIgnoringCase (...)
but I prefer to have one single way of doing things than a lot of different ways. I also see it as API pollution. That are the reasons why I introduce shortcut functions sparsely.
Please open a feature request on github. I'll add a shortcut if enough people vote for it
Until then you can add the shortcut yourself which is a one liner
c
i think the perfect api would be to have contains, which defaults to atLeast(1) and case sensitive, and then you can specify modifiers for what you want different.
r
Maybe I do not get you but that's how it is currently
c
currently if i want to make it case sensitive i also have to specify atLeast(1)
so i can either have the default contains matcher, but if i don’t want that i have to specify all options in an exact order
r
Exactly, I still don't get how that differs from
and then you can specify modifiers for what you want different.
The exact order is there for the reason that I don't want to promote different ways
Do you mean that 
contains
should be 
case insensitive
?
c
no, i dont want to have to specify all modifiers if i just want to change one thing
its not because I’m too lazy to type it, i want the tests to be nice to read, and 
atLeast(1)
adds nothing interesting
💯 1
r
I see your point. Yet, I don't intend to add shortcut fun for every possible configuration. Someone else might say 
values
does not add anything either. Please open a feature request on github: https://github.com/robstoll/atrium/issues/new?template=feature_request.md
Get others to vote for it and I concider adding the shortcut to atrium.
In the meantime you can create the shortcut fun yourself. Let me know if you need help with that.
c
i really don’t want a shortcut function
i want the api to be flexible so that i can specify only what i want to change
r
Then open a feature request for that
c
because what sense does a fluent api have when i am forced to set all values
ok
r
Currently I prevent things like: 
contains.atLeast(1).ignoreCase.exactly(2)...
For this to work I need an order
If i want to skip an option then I need a shortcut
c
to prevent it at compile time. you could still prevent it at run time with any order
r
That's not the design I want to provide because it would allow to have several ways to write the same. Something I want to prevent.
It only promotes confusion IMO
But I am willing to add shortcuts
Just not open up the API for arbitrary paths
c
ok. a good assertion lib probably needs to be opinionated.
i think having several ways to write the same is great because tests should tell a story
assert(xx).contains().inAnyOrder().values() looks very much like a builder pattern and that usually has random order, and you specify only what you want
r
I agree with the first two. Atrium provides two separate APIs, pure fluent and infix. So that useres don't have to mix both styles if they don't want. We could add another style which uses the kind of builder pattern you have in mind.
The one you have in mind is kind of tge traditional OOP pattern. The one I use is more of a functional one with immutability in mind
Both valid options IMO.
c
interesting, why is that? it can still be an immutable builder
r
As you said only at runtime. I prefer at compile time
It's like having a immutable list which provides an 
add
which only throws 
UnsupportedOperationException
. IMO ugly
c
right.
I’ll dig into the sourcecode and will try to add a new syntax
are there any docs for that?
r
Docs for what exactly?
Adding a new API style?
c
yeah and architecture
r
Nope, so far no one contributed in this way
4 Views
Open in Slack
PreviousNext
Powered by