when I write

assert

and hit code completion then I see two overloads from kotlin and then the overloads from Atrium (with

subject

as parameter name). Yet, if you hit enter in this case then it makes a full qualified call instead of importing

assert

. That's why I prefer the first way of importing Atrium's assert

had to disable auto-import in AS, seems to be better now. Btw,

isTrue()

is gone or maybe moved somewhere compared to

0.6.0

?

yupp, I removed it in favour of

toBe(true)

IMO it does not add enough value. Do you disagree?

same for isFalse and isNull =>

toBe(false)

,

toBe(null)

I figured it is more idiomatic/consistent to use always the same function for equality checks

don't have a strong opinion, used to

isTrue

in assertJ, but imho

toBe(true)

is equally readable. So yeah.. the only think to consider is slightly pissed people that had

isTrue

before)

Yeah... maybe I was a bit overly strong in adhere to the principle only one way of doing things: There is a migration guide with regex replacements: https://github.com/robstoll/atrium/releases#migration

search for: isTrue\(\) replace with: toBe(true) search for: isFalse\(\) replace with: toBe(false) search for: import ch.en_GB.is(?:True|False)([\S\s])(import ch.*en_GB).is(?:True|False) replace with: $1$2.toBe search for: isNull\(\) replace with: toBe(null)

What do you think, should I re-add those aliases?

I understand your idea of not polluting the framework and having one generic

toBe

function. Either you keep it lean and community will come up with atrium extension library that will contain verbs for every taste, or you collect some feedback for a while and do the changes with the highest number of votes.

either way, I wouldn't jump into back and forth refactorings only because of one random Joe like myself) I can imagine how time consuming it is, seems like you made your mind with

toBe

, let the dust settle and chances are people will like it like this.

Thanks for your feedback 🙂

@robstoll I have this (just updated to 0.7.0, but still have the problem):

if (cxt2.expected == null)
						assertThat(result).toBe(null)
					else
						assertThat(result).notToBeNullBut(cxt2.expected)

It tells me that

cxt2.expected

is not a subtype of Any... it's nullable, but I have the null check no?

When I add

!!

it works... but it's a bit ugly...

Maybe because it's a

val expected: SomeType? get() = ...

?

Never mind, I guess that's probably why the null check wouldn't help... I'll have to settle with

!!

in this case.

Nope, I switched to

by lazy { }

and still have the problem... unless lazy also doesn't support smart casts..

Is expected a

var

? If so then the problem is that the var could have changed since the null check and thus kotlin cannot apply s smart cast. Assign it to a local variable and it should work

are there plans to supply something like kotlin-test’s or scala-test´s

Eventually

?

At least for the JS Platform. I have already uses cases where I would want to be able to write specs involving Promises

oh... you are talking about concurrency not asynchronicity. Well, at the moment not, since I don't have a use case myself

but feel free to open a feature request 🙂 https://github.com/robstoll/atrium/issues/new?template=feature_request.md

ok

i’m not even sure if waiting for a condition should be part of a test framework or assertion lib. it could be just a small library. i have written something like that over and over again on different programming gigs and i don’t want to write it again 🙂

Usually the way I handle that kind of thing is to pass a mock callback to the promise & validate it gets invoked with the correct params

you (generally) don’t want actual concurrency / async happening in unit-level tests

i need it for intergration tests, where i test that a new server syncs with the cluster. and it can take some seconds but i don’t want to sleep for the worst case

in unit tests i totally agree with you

how can i rewrite this assertion with a contains matcher:

assert(names.any { it.canonicalName.contains("blah") }).toBe(true)

Writting from my phone, so bear with me:

assert(names).any {
  property(subject::canonicalName).contains("foo")
}