You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dolphinscheduler.apache.org by JUN GAO <ga...@gmail.com> on 2020/08/01 09:21:12 UTC

Re: [DISCUSS] UT specification of DS

1. About DS ut test (maybe include database)

I agree with you.  Mockito is a powerful architecture, it is very simple to
write unit tests with it.

CalvinKirs <ac...@163.com> 于2020年7月31日周五 下午10:36写道:

> I agree with you, but some aspects need to be discussed. We should not put
> the test logic of zk and database in the e2e test. This is a bit cumbersome
> and does not meet the unit test specification. Regarding the unit test of
> the server module, I will come up with a plan and complete it later.
>
>
> Best  wishes!
> CalvinKirs
>
>
> On 07/31/2020 21:07,Yichao Yang<10...@qq.com> wrote:
> Hi all,
>
>
> The purpose of this discussion is to discuss the UT specification of DS.
>
>
> My thoughts are as follows:
>
>
> 1. About DS ut test (maybe include database)
>
>
> Using framework: mockito, powermockito
> Reason: The purpose of UT is to cover a function for simple test. We can
> not or do not need to just place all the test verification process on ut.
> Therefore, it is necessary to restore the essence of UT and simplify the
> difficulty of writing UT.
> For example: If UT is used to test the whole process of an API, there will
> be a lot of conditions to be considered. It will be difficult to consider
> each condition. However, if we only direct each ut to the corresponding
> method and cover this method as completely as possible, the error rate of
> functional testing will be greatly reduced.
>
>
> 2. About ZK, front end test, (may be include database)
>
>
> Module: put this part of the test in the E2E module
>
>
> Reason: because these components are end-to-end originally, which is
> conducive to module division.
>
>
>
> -------------------
>
>
> 各位社区同学们,大家好:
>
>
> 这次讨论的目的:讨论关于ds的ut编写规范。
>
>
> 我的想法如下:
> 1.关于ds ut测试(可以包含数据库):
> 使用框架:Mockito,PowerMockito
> 目的:还原ut的本质,简化ut,但依然发挥ut的最大作用,并且降低ut编写的难度。
>
> 原因:ut的目的就是为了简单的测试覆盖一个函数,我们不可能也不需要把所有的测试验证过程都寄托于ut。所以还原ut的本质,简化ut编写难度是一个相对较好的选择。
>
> 举个例子:如果ut用来测试一个api的整个流程,其中需要考虑的条件判断会非常多,去吧每一种条件都考虑到会比较难。但是如果我们将每个ut只正对对应的方法上,并将这个方法覆盖尽可能完全,那么功能性测试的错误率会大大降低。
>
>
> 2.关于zk,前端测试,(可以包含数据库)
> 模块:将这部分的测试放在e2e模块
> 原因:因为这些都是数据端对端的测试,利于模块划分。
>
>
> If you have any opinions or suggestions, welcome to put forward.
>
>
> Best,
> Yichao Yang



-- 

DolphinScheduler(Incubator)  PPMC
Jun Gao 高俊
gaojun2048@gmail.com