osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CALCITE-2458 Use of Kotlin for unit tests


Il mar 18 set 2018, 09:42 Vladimir Sitnikov <sitnikov.vladimir@xxxxxxxxx>
ha scritto:

> Julian>I'd like to hear from Calcite contributors - would you be prepared
> Julian>to take the time to learn Kotlin?
>
> We do not force everybody to write tests in Kotlin.
> However, writing tests in Kotlin might be a fun way of studying both Kotlin
> and Calcite which might be a great option for contributors.
>
> That is exactly what Michael is saying:
>
> Michael> it's the excuse I've been looking for to finally write some
> Kotlin.
>
>
> TL;DR of below: I would agree that adding a new technology is a thing.
> However I would disagree with both of the provided examples
> (SQLLine+JMockit; Druid+Mockito) after I have studied the relevant code.
>
> Julian>Once code is written, it is in the project forever
>
> The code can be removed.
>
> Julian>I can't even figure out how to even run the
> Julian>JMockit-based test in SQLLine.
>
> Julian, would you please care explain a bit more here?
>
> Your words might sound like "I can't figure out how to even run
> Kotlin-based test in Calcite",
> however as my PR shows, regular `mvn test` just works. I can easily run and
> debug tests from within IDEA.
>
> I've just downloaded SQLLine code, and SqlLineArgsTest runs as a part of
> mvn test, so what's the problem?
> Note: there's a failure (see
> https://github.com/julianhyde/sqlline/issues/154 ) which is NOT related to
> JMockit.
>
> Julian>I have regrets about allowing Mockito into Calcite (it is only used
> in
> Julian>the Druid adapter)
>
> DruidQueryFilterTest is the only test that uses Mockito.
> Apparently the test is trying to test STATIC DruidJsonFilter.toDruidFilters
> method, however
> due to some coding issues that method still requires certain (unknown) bits
> of DruidQuery which is extremely hard to instantiate.
>
> Does that mean Mockito is to blame there? I wouldn't say so.
> Mockito helps there to cut corners.
>
> Would it be better if we've spend 2-4+months on DruidQuery/DruidJsonFilter
> code design and review that could be testable without Mockito/JMockit?
> I doubt so.
>
> On top of that, the whole Druid thing is of much-much higher barrier to me
> rather than
> simple things like Mockito/JMockit/Java/Kotlin.
>


I think that using Mockito/PowerMock nowadays is standard practice in
modern Java libraries and application development.  It is not easy but it
is a very useful tool. So +10 from me.

I have never used Kotlin, but when you introduce it, it is like forever, if
you what to drop it you have to rewrite tests and no one has time and
resources to spend on such activities.

I don't know if Kotlin is enough widespread to say that it won't be a
problem for new contributors. When you are new you already have to enter
the world of new concepts and learn how the test suite are organised...

I sponsor the idea of having domain specific test languages like QUIDEM
which make it simpler to write complex assertions in this SQL/Calcite
environment.

So from me it is more like a -0 for Kotlin now

My two cents
Enrico


> Vladimir
>
-- 


-- Enrico Olivelli