Hi,

Actually  JavaDB do have network drivers [1].

[1] http://db.apache.org/derby/papers/DerbyTut/ns_intro.html

Thanks,

On Fri, May 19, 2017 at 11:35 AM, Uvindra Dias Jayasinha <[email protected]>
wrote:

> FYI let me give some details regarding how we are testing the APIM DAO
> layer for C5.
>
> 1. The DAO layer is an interface that the rest of our code interacts with
> in order to store and retrieve data. We mock the DOA layer and can control
> its behaviour to unit test how the rest of our code behaves when
> interacting with it.
>
> 2. The implementation of the DAO interface will actually be communicating
> with the database. Since this is the case unit testing the DAO
> implementation does not give much of a benefit. So when it comes to testing
> the actual DAO implementation we are running automated integration tests
> with various DB docker images running(We test against H2, MySQL, Oracle,
> PostgreSQL, SQLServer)
>
>
> I believe trying to unit test the DAO implementation will only give you a
> false sense of security. You are better off doing actual integration tests
> for these
>
>
> On 19 May 2017 at 10:53, Sanjiva Weerawarana <[email protected]> wrote:
>
>> I didn't realize there was a version of Derby in the JDK! Yes we should
>> support it as a real DB now and can we even use it in production?? That
>> would be awesome as it'll reduce complexity for smaller deployments - just
>> download and run.
>>
>> Earlier IIRC Derby didn't have networked drivers and therefore couldn't
>> be set up for simple 2-node HA. If that has changed that's great.
>>
>> Sanjiva.
>>
>> On Fri, May 19, 2017 at 9:31 AM, Asanka Abeyweera <[email protected]>
>> wrote:
>>
>>> Does this mean we are adding Derby to the list of supported RDBMS for MB
>>> 4.0.0?
>>>
>>> On Fri, May 19, 2017 at 9:05 AM, Pumudu Ruhunage <[email protected]>
>>> wrote:
>>>
>>>> Can we consider javaDB(Derby)[1] which is part of JDK. since it's
>>>> shipped with jdk, it'll be more suitable for unit tests instead of going
>>>> for external databases/frameworks.
>>>> Since we are not using any vendor-specific sql's in DAO it
>>>> should support all required sql syntaxes without any issue.
>>>>
>>>> [1] http://www.oracle.com/technetwork/java/javadb/overview/j
>>>> avadb-156712.html
>>>>
>>>> Thanks,
>>>>
>>>> On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[email protected]>
>>>> wrote:
>>>>
>>>>> (+) Adding @architecture
>>>>>
>>>>> On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Are we planning to use stored procedures? If yes better to use a
>>>>>> framework that is flexible enough.
>>>>>>
>>>>>> On Thu, May 18, 2017 at 10:59 AM, Ramith Jayasinghe <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> if you want to mess with the database/data, this is the lib for that
>>>>>>> (regardless of the test type).
>>>>>>>
>>>>>>> On Thu, May 18, 2017 at 10:48 AM, Manuri Amaya Perera <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> @Hasitha Actually that was for integration tests. I guess Ramith's
>>>>>>>> suggestion would be better for unit tests. When writing integration 
>>>>>>>> tests
>>>>>>>> we could look into the possibility of having containerized databases.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Manuri
>>>>>>>>
>>>>>>>> On Thu, May 18, 2017 at 10:42 AM, Ramith Jayasinghe <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> I propose using http://dbunit.sourceforge.net.
>>>>>>>>> easy api. and allows you to insert data into database before the
>>>>>>>>> test and then clean up etc etc.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, May 18, 2017 at 10:40 AM, Fazlan Nazeem <[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Manuri,
>>>>>>>>>>>
>>>>>>>>>>> Was this approach taken for unit tests or integration tests?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This approach was taken for integration testing in APIM.
>>>>>>>>>>
>>>>>>>>>> For unit testing we are using Mockito framework for mocking out
>>>>>>>>>> dependencies.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, May 18, 2017 at 10:31 AM, Manuri Amaya Perera <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Pamod,
>>>>>>>>>>>>
>>>>>>>>>>>> API Manager team is using dynamically created containerized
>>>>>>>>>>>> databases for some tests[1]. With this approach we can perform the 
>>>>>>>>>>>> tests
>>>>>>>>>>>> for several databases types. I think they have already implemented 
>>>>>>>>>>>> this.
>>>>>>>>>>>>
>>>>>>>>>>>> Can we also do something like this?
>>>>>>>>>>>>
>>>>>>>>>>>> [1] [Build Team] Jenkins Build configuration on API Manager
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Manuri
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, May 18, 2017 at 10:23 AM, Pamod Sylvester <
>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> When unit testing DAO layers what will be the best approach we
>>>>>>>>>>>>> should be using ? some of the approaches would be the following,
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Use an in-memory database ? (h2,Derby or HSSQLDB)
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Pros*
>>>>>>>>>>>>>
>>>>>>>>>>>>>  - Easy to configure
>>>>>>>>>>>>>  - SQL query executions will be covered
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Cons*
>>>>>>>>>>>>>
>>>>>>>>>>>>>  - As mention in [1] tests will be specific to cover only the
>>>>>>>>>>>>> features covered specific to the database which is being used 
>>>>>>>>>>>>> (i.e h2)
>>>>>>>>>>>>>  - Could also be thought of as an anti pattern for unit tests
>>>>>>>>>>>>> (though it's an in-memory database this could be considered as an 
>>>>>>>>>>>>> external
>>>>>>>>>>>>> system)
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. Mock DB instance
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Pros*
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Since the control is on our side we could overcome the cons
>>>>>>>>>>>>> mentioned in the 1st approach.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Cons*
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Could make the implementation more complex in comparison to
>>>>>>>>>>>>> the 1st approach
>>>>>>>>>>>>>
>>>>>>>>>>>>> Currently IMO option 1 would be a better option. Since
>>>>>>>>>>>>> currently our code is based on ANSI SQL and we don't have 
>>>>>>>>>>>>> triggers, PLSQL
>>>>>>>>>>>>> (which will be database specific syntax which will require us to 
>>>>>>>>>>>>> do mocks).
>>>>>>>>>>>>> thoughts ? will there be a better option ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://blog.jooq.org/tag/unit-testing/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Pamod
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Pamod Sylvester *
>>>>>>>>>>>>>
>>>>>>>>>>>>> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
>>>>>>>>>>>>> cell: +94 77 7779495 <+94%2077%20777%209495>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>
>>>>>>>>>>>> *Manuri Amaya Perera*
>>>>>>>>>>>>
>>>>>>>>>>>> *Software Engineer*
>>>>>>>>>>>>
>>>>>>>>>>>> *WSO2 Inc.*
>>>>>>>>>>>>
>>>>>>>>>>>> *Blog: http://manuriamayaperera.blogspot.com
>>>>>>>>>>>> <http://manuriamayaperera.blogspot.com>*
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> *Hasitha Abeykoon*
>>>>>>>>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com
>>>>>>>>>>> *cell:* *+94 719363063*
>>>>>>>>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>
>>>>>>>>>> Fazlan Nazeem
>>>>>>>>>>
>>>>>>>>>> *Senior Software Engineer*
>>>>>>>>>>
>>>>>>>>>> *WSO2 Inc*
>>>>>>>>>> Mobile : +94772338839
>>>>>>>>>> <%2B94%20%280%29%20773%20451194>
>>>>>>>>>> [email protected]
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ramith Jayasinghe
>>>>>>>>> Technical Lead
>>>>>>>>> WSO2 Inc., http://wso2.com
>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>
>>>>>>>>> E: [email protected]
>>>>>>>>> P: +94 777542851 <+94%2077%20754%202851>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> *Manuri Amaya Perera*
>>>>>>>>
>>>>>>>> *Software Engineer*
>>>>>>>>
>>>>>>>> *WSO2 Inc.*
>>>>>>>>
>>>>>>>> *Blog: http://manuriamayaperera.blogspot.com
>>>>>>>> <http://manuriamayaperera.blogspot.com>*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ramith Jayasinghe
>>>>>>> Technical Lead
>>>>>>> WSO2 Inc., http://wso2.com
>>>>>>> lean.enterprise.middleware
>>>>>>>
>>>>>>> E: [email protected]
>>>>>>> P: +94 777542851 <+94%2077%20754%202851>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Asanka Abeyweera
>>>>>> Senior Software Engineer
>>>>>> WSO2 Inc.
>>>>>>
>>>>>> Phone: +94 712228648 <071%20222%208648>
>>>>>> Blog: a5anka.github.io
>>>>>>
>>>>>> <https://wso2.com/signature>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Pamod Sylvester *
>>>>>
>>>>> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
>>>>> cell: +94 77 7779495 <+94%2077%20777%209495>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Pumudu Ruhunage
>>>> Software Engineer | WSO2 Inc
>>>> M: +94 779 664493  | http://wso2.com
>>>> <https://wso2.com/signature>
>>>>
>>>
>>>
>>>
>>> --
>>> Asanka Abeyweera
>>> Senior Software Engineer
>>> WSO2 Inc.
>>>
>>> Phone: +94 712228648 <+94%2071%20222%208648>
>>> Blog: a5anka.github.io
>>>
>>> <https://wso2.com/signature>
>>>
>>
>>
>>
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
>> email: [email protected]; office: (+1 650 745 4499 <(650)%20745-4499> |
>> +94  11 214 5345) x5700; cell: +94 77 787 6880 <+94%2077%20787%206880> | +1
>> 408 466 5099 <(408)%20466-5099>; voip: +1 650 265 8311 <(650)%20265-8311>;
>> twitter: @sanjiva
>> Lean . Enterprise . Middleware
>>
>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 777733962
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Malaka.
-- 
Malaka Gangananda - Software Engineer | WSO2
Email : [email protected]
Mobile : +94713564340
Web : http://wso2.com
  <http://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to