You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by Ankush Mishra <an...@gmail.com> on 2018/11/04 05:49:22 UTC

Unit Tests

Hello Maxim,

I was wondering what sort of tests to write, here's a couple from the top
of my head:

 - SyncMethod test
 - Verify syncing for all the handlers
 - UI tests (not sure what to test here other than the forms)
 - IcalUtils tests

Those are just off the top of my head. Anything else you want add to this?

Also, from my side, here's where I am thinking of placing them:

 - SyncMethod, IcalUtils, under o.a.openmeetings.service
 - Syncing Handlers (Requires access to the Dao), UI under
o.a.openmeetings.web

One last thing, I don't know if this was brought up, but can we have a
batch update for appointments? This would reduce perhaps load on the DB,
although, not sure how often there are users using the Calendaring feature
on OM.

Regards
Ankush

Re: Unit Tests

Posted by Ankush Mishra <an...@gmail.com>.
Got it, thanks!

Regards
Ankush

On Sun, Nov 4, 2018 at 6:30 PM Maxim Solodovnik <so...@gmail.com>
wrote:

> I mean to implement bulk update
> you can add following method to AppointmentDao:
>
> public void update(List<Appointment> appts, Long userId) {
>     for (Appointment a : appts) {
>          update(a, userId);
>     }
> }
>
> Performance can easily be checked by unit test :)
>
> On Sun, 4 Nov 2018 at 15:31, Ankush Mishra <an...@gmail.com>
> wrote:
>
>> Thanks for letting me know. Will do, based on the criteria you specified.
>>
>> For Appointment Bulk update, do you mean introduce a transactional
>> function, which calls updateAppointment in a for loop?
>>
>>
>> On Sun, Nov 4, 2018 at 12:42 PM Maxim Solodovnik <so...@gmail.com>
>> wrote:
>>
>>> Bulk update can easily being added to the Dao
>>>
>>> since method will be transactional, it should be something like "update
>>> in the loop", transaction will be commited only once, and it might speed-up
>>> the code
>>>
>>> On Sun, 4 Nov 2018 at 13:58, Maxim Solodovnik <so...@gmail.com>
>>> wrote:
>>>
>>>> Hello Ankush,
>>>>
>>>> If your tests will need fully functional OM (i.e. all Daos, beans,
>>>> managers etc.) it need to be placed under tests for openmeetings-web project
>>>> Packages are up to you :) it is extremely easy to refactor :)
>>>>
>>>> In case your tests will be "isolated" i.e. all mocked, or it will test
>>>> some utility methods you can place it under the module the tested class is
>>>>
>>>> Additionally you can check our Sonar instance:
>>>> https://builds.apache.org/analysis/overview?id=org.apache.openmeetings%3Aopenmeetings-parent
>>>> to check what else can be tested :)
>>>>
>>>>
>>>> On Sun, 4 Nov 2018 at 12:49, Ankush Mishra <an...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hello Maxim,
>>>>>
>>>>> I was wondering what sort of tests to write, here's a couple from the
>>>>> top of my head:
>>>>>
>>>>>  - SyncMethod test
>>>>>  - Verify syncing for all the handlers
>>>>>  - UI tests (not sure what to test here other than the forms)
>>>>>  - IcalUtils tests
>>>>>
>>>>> Those are just off the top of my head. Anything else you want add to
>>>>> this?
>>>>>
>>>>> Also, from my side, here's where I am thinking of placing them:
>>>>>
>>>>>  - SyncMethod, IcalUtils, under o.a.openmeetings.service
>>>>>  - Syncing Handlers (Requires access to the Dao), UI under
>>>>> o.a.openmeetings.web
>>>>>
>>>>> One last thing, I don't know if this was brought up, but can we have a
>>>>> batch update for appointments? This would reduce perhaps load on the DB,
>>>>> although, not sure how often there are users using the Calendaring feature
>>>>> on OM.
>>>>>
>>>>> Regards
>>>>> Ankush
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>
>
> --
> WBR
> Maxim aka solomax
>

Re: Unit Tests

Posted by Maxim Solodovnik <so...@gmail.com>.
I mean to implement bulk update
you can add following method to AppointmentDao:

public void update(List<Appointment> appts, Long userId) {
    for (Appointment a : appts) {
         update(a, userId);
    }
}

Performance can easily be checked by unit test :)

On Sun, 4 Nov 2018 at 15:31, Ankush Mishra <an...@gmail.com> wrote:

> Thanks for letting me know. Will do, based on the criteria you specified.
>
> For Appointment Bulk update, do you mean introduce a transactional
> function, which calls updateAppointment in a for loop?
>
>
> On Sun, Nov 4, 2018 at 12:42 PM Maxim Solodovnik <so...@gmail.com>
> wrote:
>
>> Bulk update can easily being added to the Dao
>>
>> since method will be transactional, it should be something like "update
>> in the loop", transaction will be commited only once, and it might speed-up
>> the code
>>
>> On Sun, 4 Nov 2018 at 13:58, Maxim Solodovnik <so...@gmail.com>
>> wrote:
>>
>>> Hello Ankush,
>>>
>>> If your tests will need fully functional OM (i.e. all Daos, beans,
>>> managers etc.) it need to be placed under tests for openmeetings-web project
>>> Packages are up to you :) it is extremely easy to refactor :)
>>>
>>> In case your tests will be "isolated" i.e. all mocked, or it will test
>>> some utility methods you can place it under the module the tested class is
>>>
>>> Additionally you can check our Sonar instance:
>>> https://builds.apache.org/analysis/overview?id=org.apache.openmeetings%3Aopenmeetings-parent
>>> to check what else can be tested :)
>>>
>>>
>>> On Sun, 4 Nov 2018 at 12:49, Ankush Mishra <an...@gmail.com>
>>> wrote:
>>>
>>>> Hello Maxim,
>>>>
>>>> I was wondering what sort of tests to write, here's a couple from the
>>>> top of my head:
>>>>
>>>>  - SyncMethod test
>>>>  - Verify syncing for all the handlers
>>>>  - UI tests (not sure what to test here other than the forms)
>>>>  - IcalUtils tests
>>>>
>>>> Those are just off the top of my head. Anything else you want add to
>>>> this?
>>>>
>>>> Also, from my side, here's where I am thinking of placing them:
>>>>
>>>>  - SyncMethod, IcalUtils, under o.a.openmeetings.service
>>>>  - Syncing Handlers (Requires access to the Dao), UI under
>>>> o.a.openmeetings.web
>>>>
>>>> One last thing, I don't know if this was brought up, but can we have a
>>>> batch update for appointments? This would reduce perhaps load on the DB,
>>>> although, not sure how often there are users using the Calendaring feature
>>>> on OM.
>>>>
>>>> Regards
>>>> Ankush
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>

-- 
WBR
Maxim aka solomax

Re: Unit Tests

Posted by Ankush Mishra <an...@gmail.com>.
Thanks for letting me know. Will do, based on the criteria you specified.

For Appointment Bulk update, do you mean introduce a transactional
function, which calls updateAppointment in a for loop?


On Sun, Nov 4, 2018 at 12:42 PM Maxim Solodovnik <so...@gmail.com>
wrote:

> Bulk update can easily being added to the Dao
>
> since method will be transactional, it should be something like "update in
> the loop", transaction will be commited only once, and it might speed-up
> the code
>
> On Sun, 4 Nov 2018 at 13:58, Maxim Solodovnik <so...@gmail.com>
> wrote:
>
>> Hello Ankush,
>>
>> If your tests will need fully functional OM (i.e. all Daos, beans,
>> managers etc.) it need to be placed under tests for openmeetings-web project
>> Packages are up to you :) it is extremely easy to refactor :)
>>
>> In case your tests will be "isolated" i.e. all mocked, or it will test
>> some utility methods you can place it under the module the tested class is
>>
>> Additionally you can check our Sonar instance:
>> https://builds.apache.org/analysis/overview?id=org.apache.openmeetings%3Aopenmeetings-parent
>> to check what else can be tested :)
>>
>>
>> On Sun, 4 Nov 2018 at 12:49, Ankush Mishra <an...@gmail.com>
>> wrote:
>>
>>> Hello Maxim,
>>>
>>> I was wondering what sort of tests to write, here's a couple from the
>>> top of my head:
>>>
>>>  - SyncMethod test
>>>  - Verify syncing for all the handlers
>>>  - UI tests (not sure what to test here other than the forms)
>>>  - IcalUtils tests
>>>
>>> Those are just off the top of my head. Anything else you want add to
>>> this?
>>>
>>> Also, from my side, here's where I am thinking of placing them:
>>>
>>>  - SyncMethod, IcalUtils, under o.a.openmeetings.service
>>>  - Syncing Handlers (Requires access to the Dao), UI under
>>> o.a.openmeetings.web
>>>
>>> One last thing, I don't know if this was brought up, but can we have a
>>> batch update for appointments? This would reduce perhaps load on the DB,
>>> although, not sure how often there are users using the Calendaring feature
>>> on OM.
>>>
>>> Regards
>>> Ankush
>>>
>>>
>>>
>>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
> --
> WBR
> Maxim aka solomax
>

Re: Unit Tests

Posted by Maxim Solodovnik <so...@gmail.com>.
Bulk update can easily being added to the Dao

since method will be transactional, it should be something like "update in
the loop", transaction will be commited only once, and it might speed-up
the code

On Sun, 4 Nov 2018 at 13:58, Maxim Solodovnik <so...@gmail.com> wrote:

> Hello Ankush,
>
> If your tests will need fully functional OM (i.e. all Daos, beans,
> managers etc.) it need to be placed under tests for openmeetings-web project
> Packages are up to you :) it is extremely easy to refactor :)
>
> In case your tests will be "isolated" i.e. all mocked, or it will test
> some utility methods you can place it under the module the tested class is
>
> Additionally you can check our Sonar instance:
> https://builds.apache.org/analysis/overview?id=org.apache.openmeetings%3Aopenmeetings-parent
> to check what else can be tested :)
>
>
> On Sun, 4 Nov 2018 at 12:49, Ankush Mishra <an...@gmail.com>
> wrote:
>
>> Hello Maxim,
>>
>> I was wondering what sort of tests to write, here's a couple from the top
>> of my head:
>>
>>  - SyncMethod test
>>  - Verify syncing for all the handlers
>>  - UI tests (not sure what to test here other than the forms)
>>  - IcalUtils tests
>>
>> Those are just off the top of my head. Anything else you want add to this?
>>
>> Also, from my side, here's where I am thinking of placing them:
>>
>>  - SyncMethod, IcalUtils, under o.a.openmeetings.service
>>  - Syncing Handlers (Requires access to the Dao), UI under
>> o.a.openmeetings.web
>>
>> One last thing, I don't know if this was brought up, but can we have a
>> batch update for appointments? This would reduce perhaps load on the DB,
>> although, not sure how often there are users using the Calendaring feature
>> on OM.
>>
>> Regards
>> Ankush
>>
>>
>>
>>
>
> --
> WBR
> Maxim aka solomax
>


-- 
WBR
Maxim aka solomax

Re: Unit Tests

Posted by Maxim Solodovnik <so...@gmail.com>.
Hello Ankush,

If your tests will need fully functional OM (i.e. all Daos, beans, managers
etc.) it need to be placed under tests for openmeetings-web project
Packages are up to you :) it is extremely easy to refactor :)

In case your tests will be "isolated" i.e. all mocked, or it will test some
utility methods you can place it under the module the tested class is

Additionally you can check our Sonar instance:
https://builds.apache.org/analysis/overview?id=org.apache.openmeetings%3Aopenmeetings-parent
to check what else can be tested :)


On Sun, 4 Nov 2018 at 12:49, Ankush Mishra <an...@gmail.com> wrote:

> Hello Maxim,
>
> I was wondering what sort of tests to write, here's a couple from the top
> of my head:
>
>  - SyncMethod test
>  - Verify syncing for all the handlers
>  - UI tests (not sure what to test here other than the forms)
>  - IcalUtils tests
>
> Those are just off the top of my head. Anything else you want add to this?
>
> Also, from my side, here's where I am thinking of placing them:
>
>  - SyncMethod, IcalUtils, under o.a.openmeetings.service
>  - Syncing Handlers (Requires access to the Dao), UI under
> o.a.openmeetings.web
>
> One last thing, I don't know if this was brought up, but can we have a
> batch update for appointments? This would reduce perhaps load on the DB,
> although, not sure how often there are users using the Calendaring feature
> on OM.
>
> Regards
> Ankush
>
>
>
>

-- 
WBR
Maxim aka solomax