Re: [MB] Best Approach to write unit tests for DAO Layer ?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Pamod Sylvester
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: +94 77 7779495

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Pumudu Ruhunage
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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Asanka Abeyweera
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 <[hidden email]> 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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: +94 712228648



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Sanjiva Weerawarana-2
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 <[hidden email]> 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 <[hidden email]> 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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:+94%2071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Sanjiva Weerawarana, Ph.D.
Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
email: [hidden email]; office: (+1 650 745 4499 | +94  11 214 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311; twitter: @sanjiva
Lean . Enterprise . Middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Dharshana Warusavitharana
Hi All,

The correct approach for unit test is to mock DB layer using Mockito or Jmockit. Not introduce DB layer. Anyway, you have to write set of integration test to test actual functionality with actual DB and the actual end to end use case. 

But the correct approach is to mock the DB layer just refer stack overflow answer in [1]. 


Thank you,
Dharshana.

On Fri, May 19, 2017 at 10:53 AM, Sanjiva Weerawarana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:+94%2071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Sanjiva Weerawarana, Ph.D.
Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
email: [hidden email]; office: <a href="tel:+1%20650-745-4499" value="+16507454499" target="_blank">(+1 650 745 4499 | +94  11 214 5345) x5700; cell: <a href="tel:077%20787%206880" value="+94777876880" target="_blank">+94 77 787 6880 | <a href="tel:+1%20408-466-5099" value="+14084665099" target="_blank">+1 408 466 5099; voip: <a href="tel:+1%20650-265-8311" value="+16502658311" target="_blank">+1 650 265 8311; twitter: @sanjiva
Lean . Enterprise . Middleware



--

Dharshana Warusavitharana
Associate Technical Lead
Fax :+94 11 2145300 
cell : +94770342233
bloghttp://dharshanaw.blogspot.com

lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Uvindra Dias Jayasinha
In reply to this post by Sanjiva Weerawarana-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:+94%2071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Sanjiva Weerawarana, Ph.D.
Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
email: [hidden email]; office: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">(+1 650 745 4499 | +94  11 214 5345) x5700; cell: <a href="tel:+94%2077%20787%206880" value="+94777876880" target="_blank">+94 77 787 6880 | <a href="tel:(408)%20466-5099" value="+14084665099" target="_blank">+1 408 466 5099; voip: <a href="tel:(650)%20265-8311" value="+16502658311" target="_blank">+1 650 265 8311; twitter: @sanjiva
Lean . Enterprise . Middleware



--
Regards,
Uvindra

Mobile: 777733962

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Fazlan Nazeem
To add to Uvindra and Darshana's comments.
 
Trying to run integration test with a specific db will only validate that our code functions well with that specific db. With the docker image approach, we can validate our code functions properly with all those databases. 

On Fri, May 19, 2017 at 11:35 AM, Uvindra Dias Jayasinha <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:+94%2071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Sanjiva Weerawarana, Ph.D.
Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
email: [hidden email]; office: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">(+1 650 745 4499 | +94  11 214 5345) x5700; cell: <a href="tel:+94%2077%20787%206880" value="+94777876880" target="_blank">+94 77 787 6880 | <a href="tel:(408)%20466-5099" value="+14084665099" target="_blank">+1 408 466 5099; voip: <a href="tel:(650)%20265-8311" value="+16502658311" target="_blank">+1 650 265 8311; twitter: @sanjiva
Lean . Enterprise . Middleware



--
Regards,
Uvindra

Mobile: 777733962



--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Malaka Gangananda
In reply to this post by Uvindra Dias Jayasinha
Hi,

Actually  JavaDB do have network drivers [1].


Thanks,

On Fri, May 19, 2017 at 11:35 AM, Uvindra Dias Jayasinha <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:+94%2071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Sanjiva Weerawarana, Ph.D.
Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
email: [hidden email]; office: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">(+1 650 745 4499 | +94  11 214 5345) x5700; cell: <a href="tel:+94%2077%20787%206880" value="+94777876880" target="_blank">+94 77 787 6880 | <a href="tel:(408)%20466-5099" value="+14084665099" target="_blank">+1 408 466 5099; voip: <a href="tel:(650)%20265-8311" value="+16502658311" target="_blank">+1 650 265 8311; twitter: @sanjiva
Lean . Enterprise . Middleware



--
Regards,
Uvindra

Mobile: 777733962

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Malaka. 
-- 
Malaka Gangananda - Software Engineer | WSO2
Mobile : +94713564340

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Dharshana Warusavitharana
Hi Fazlan,

By using docker you are writing an Integration test, not a unit test. If you are using integration approach with docker its waste to test with in-memory databases. Just use read database like mysql. 

But still, if you need to validate DAO in unit layer (at component build time) you need to mock these database layers. 


The importance of having unit test layer is you can validate any issue before it reaches the feature and bundle with the product. Once it bundles with the produce cost of fix is high. So the point of the unit test is eliminating that. 

So if you are talking about unit test, they must at least cover this aspect. Else forget this test layer and write end to end integration test using docker or what ever. But they are Integration tests and have the cost i mentioned above. 

Thank you,
Dharshana. 

On Fri, May 19, 2017 at 11:53 AM, Malaka Gangananda <[hidden email]> wrote:
Hi,

Actually  JavaDB do have network drivers [1].


Thanks,

On Fri, May 19, 2017 at 11:35 AM, Uvindra Dias Jayasinha <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:+94%2071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Sanjiva Weerawarana, Ph.D.
Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
email: [hidden email]; office: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">(+1 650 745 4499 | +94  11 214 5345) x5700; cell: <a href="tel:+94%2077%20787%206880" value="+94777876880" target="_blank">+94 77 787 6880 | <a href="tel:(408)%20466-5099" value="+14084665099" target="_blank">+1 408 466 5099; voip: <a href="tel:(650)%20265-8311" value="+16502658311" target="_blank">+1 650 265 8311; twitter: @sanjiva
Lean . Enterprise . Middleware



--
Regards,
Uvindra

Mobile: 777733962

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Malaka. 
-- 
Malaka Gangananda - Software Engineer | WSO2
Mobile : <a href="tel:071%20356%204340" value="+94713564340" target="_blank">+94713564340

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Dharshana Warusavitharana
Associate Technical Lead
Fax :+94 11 2145300 
cell : +94770342233
bloghttp://dharshanaw.blogspot.com

lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Fazlan Nazeem
Hi Darshana,

For unit testing, the correct approach is to mock the db layer as you have pointed out. But that alone is not sufficient for DAO testing. We need integration tests that would validate that our code integrates fine with the database. For this, Docker approach would be beneficial because it provides the ability to test with several databases. 
 


On Fri, May 19, 2017 at 12:56 PM, Dharshana Warusavitharana <[hidden email]> wrote:
Hi Fazlan,

By using docker you are writing an Integration test, not a unit test. If you are using integration approach with docker its waste to test with in-memory databases. Just use read database like mysql. 

But still, if you need to validate DAO in unit layer (at component build time) you need to mock these database layers. 


The importance of having unit test layer is you can validate any issue before it reaches the feature and bundle with the product. Once it bundles with the produce cost of fix is high. So the point of the unit test is eliminating that. 

So if you are talking about unit test, they must at least cover this aspect. Else forget this test layer and write end to end integration test using docker or what ever. But they are Integration tests and have the cost i mentioned above. 

Thank you,
Dharshana. 

On Fri, May 19, 2017 at 11:53 AM, Malaka Gangananda <[hidden email]> wrote:
Hi,

Actually  JavaDB do have network drivers [1].


Thanks,

On Fri, May 19, 2017 at 11:35 AM, Uvindra Dias Jayasinha <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:+94%2071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Sanjiva Weerawarana, Ph.D.
Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
email: [hidden email]; office: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">(+1 650 745 4499 | +94  11 214 5345) x5700; cell: <a href="tel:+94%2077%20787%206880" value="+94777876880" target="_blank">+94 77 787 6880 | <a href="tel:(408)%20466-5099" value="+14084665099" target="_blank">+1 408 466 5099; voip: <a href="tel:(650)%20265-8311" value="+16502658311" target="_blank">+1 650 265 8311; twitter: @sanjiva
Lean . Enterprise . Middleware



--
Regards,
Uvindra

Mobile: 777733962

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Malaka. 
-- 
Malaka Gangananda - Software Engineer | WSO2
Mobile : <a href="tel:071%20356%204340" value="+94713564340" target="_blank">+94713564340

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Dharshana Warusavitharana
Associate Technical Lead
Fax :<a href="tel:+94%2011%202%20145300" value="+94112145300" target="_blank">+94 11 2145300 
cell : <a href="tel:+94%2077%20034%202233" value="+94770342233" target="_blank">+94770342233
bloghttp://dharshanaw.blogspot.com

lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Rajith Roshan
In reply to this post by Dharshana Warusavitharana
Hi,


On Fri, May 19, 2017 at 12:56 PM, Dharshana Warusavitharana <[hidden email]> wrote:
Hi Fazlan,

By using docker you are writing an Integration test, not a unit test. If you are using integration approach with docker its waste to test with in-memory databases. Just use read database like mysql. 

But still, if you need to validate DAO in unit layer (at component build time) you need to mock these database layers. 
I think there is slight confusion about unit test and integration test.
In APIM we mock DAO interface which are our unit tests. When we use docker images the DAO layer does get tested against the actual DB. This is also done at the component building time. As C4 these are not run when the product is running. These are still executed when components are building.   Since these tests are actually running against a database, these are not unit tests, they are actually integration tests used at the component building time.

Thanks!
Rajith


The importance of having unit test layer is you can validate any issue before it reaches the feature and bundle with the product. Once it bundles with the produce cost of fix is high. So the point of the unit test is eliminating that. 

So if you are talking about unit test, they must at least cover this aspect. Else forget this test layer and write end to end integration test using docker or what ever. But they are Integration tests and have the cost i mentioned above. 

Thank you,
Dharshana. 

On Fri, May 19, 2017 at 11:53 AM, Malaka Gangananda <[hidden email]> wrote:
Hi,

Actually  JavaDB do have network drivers [1].


Thanks,

On Fri, May 19, 2017 at 11:35 AM, Uvindra Dias Jayasinha <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:+94%2071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Sanjiva Weerawarana, Ph.D.
Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
email: [hidden email]; office: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">(+1 650 745 4499 | +94  11 214 5345) x5700; cell: <a href="tel:+94%2077%20787%206880" value="+94777876880" target="_blank">+94 77 787 6880 | <a href="tel:(408)%20466-5099" value="+14084665099" target="_blank">+1 408 466 5099; voip: <a href="tel:(650)%20265-8311" value="+16502658311" target="_blank">+1 650 265 8311; twitter: @sanjiva
Lean . Enterprise . Middleware



--
Regards,
Uvindra

Mobile: 777733962

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Malaka. 
-- 
Malaka Gangananda - Software Engineer | WSO2
Mobile : <a href="tel:071%20356%204340" value="+94713564340" target="_blank">+94713564340

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Dharshana Warusavitharana
Associate Technical Lead
Fax :<a href="tel:+94%2011%202%20145300" value="+94112145300" target="_blank">+94 11 2145300 
cell : <a href="tel:+94%2077%20034%202233" value="+94770342233" target="_blank">+94770342233
bloghttp://dharshanaw.blogspot.com

lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Pumudu Ruhunage
Hi,
We can not replace unit tests with integration tests and vice versa. Unit tests are for testing smallest testable units(usually per method) and integration tests are to cover high-level functionalities of the system when different modules integrated. Main idea of unit testing is that identify bugs/regressions in initial stages before propagating them to integration level.

AFAIU question here is choosing unit test approach(mock databases) or integration test approach(use an existing database) for testing MB DAO layer?

IMO since we have planned to write separate integration test suite, it's better to go with option-2 (mock db approach) for DAO layer testing if possible.

Thanks,

On Fri, May 19, 2017 at 2:33 PM, Rajith Roshan <[hidden email]> wrote:
Hi,


On Fri, May 19, 2017 at 12:56 PM, Dharshana Warusavitharana <[hidden email]> wrote:
Hi Fazlan,

By using docker you are writing an Integration test, not a unit test. If you are using integration approach with docker its waste to test with in-memory databases. Just use read database like mysql. 

But still, if you need to validate DAO in unit layer (at component build time) you need to mock these database layers. 
I think there is slight confusion about unit test and integration test.
In APIM we mock DAO interface which are our unit tests. When we use docker images the DAO layer does get tested against the actual DB. This is also done at the component building time. As C4 these are not run when the product is running. These are still executed when components are building.   Since these tests are actually running against a database, these are not unit tests, they are actually integration tests used at the component building time.

Thanks!
Rajith


The importance of having unit test layer is you can validate any issue before it reaches the feature and bundle with the product. Once it bundles with the produce cost of fix is high. So the point of the unit test is eliminating that. 

So if you are talking about unit test, they must at least cover this aspect. Else forget this test layer and write end to end integration test using docker or what ever. But they are Integration tests and have the cost i mentioned above. 

Thank you,
Dharshana. 

On Fri, May 19, 2017 at 11:53 AM, Malaka Gangananda <[hidden email]> wrote:
Hi,

Actually  JavaDB do have network drivers [1].


Thanks,

On Fri, May 19, 2017 at 11:35 AM, Uvindra Dias Jayasinha <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:+94%2071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Sanjiva Weerawarana, Ph.D.
Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
email: [hidden email]; office: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">(+1 650 745 4499 | +94  11 214 5345) x5700; cell: <a href="tel:+94%2077%20787%206880" value="+94777876880" target="_blank">+94 77 787 6880 | <a href="tel:(408)%20466-5099" value="+14084665099" target="_blank">+1 408 466 5099; voip: <a href="tel:(650)%20265-8311" value="+16502658311" target="_blank">+1 650 265 8311; twitter: @sanjiva
Lean . Enterprise . Middleware



--
Regards,
Uvindra

Mobile: 777733962

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Malaka. 
-- 
Malaka Gangananda - Software Engineer | WSO2
Mobile : <a href="tel:071%20356%204340" value="+94713564340" target="_blank">+94713564340

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Dharshana Warusavitharana
Associate Technical Lead
Fax :<a href="tel:+94%2011%202%20145300" value="+94112145300" target="_blank">+94 11 2145300 
cell : <a href="tel:+94%2077%20034%202233" value="+94770342233" target="_blank">+94770342233
bloghttp://dharshanaw.blogspot.com

lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Pumudu Ruhunage
Software Engineer | WSO2 Inc

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB] Best Approach to write unit tests for DAO Layer ?

Uvindra Dias Jayasinha
Just to be clear, no one is saying to replace unit testing with integration testing. Just that somethings are better handled as integration tests.

It is up to the MB team to decide what is the best approach that suits their requirement. We have just shared what we are using for APIM

On 21 May 2017 at 07:46, Pumudu Ruhunage <[hidden email]> wrote:
Hi,
We can not replace unit tests with integration tests and vice versa. Unit tests are for testing smallest testable units(usually per method) and integration tests are to cover high-level functionalities of the system when different modules integrated. Main idea of unit testing is that identify bugs/regressions in initial stages before propagating them to integration level.

AFAIU question here is choosing unit test approach(mock databases) or integration test approach(use an existing database) for testing MB DAO layer?

IMO since we have planned to write separate integration test suite, it's better to go with option-2 (mock db approach) for DAO layer testing if possible.

Thanks,

On Fri, May 19, 2017 at 2:33 PM, Rajith Roshan <[hidden email]> wrote:
Hi,


On Fri, May 19, 2017 at 12:56 PM, Dharshana Warusavitharana <[hidden email]> wrote:
Hi Fazlan,

By using docker you are writing an Integration test, not a unit test. If you are using integration approach with docker its waste to test with in-memory databases. Just use read database like mysql. 

But still, if you need to validate DAO in unit layer (at component build time) you need to mock these database layers. 
I think there is slight confusion about unit test and integration test.
In APIM we mock DAO interface which are our unit tests. When we use docker images the DAO layer does get tested against the actual DB. This is also done at the component building time. As C4 these are not run when the product is running. These are still executed when components are building.   Since these tests are actually running against a database, these are not unit tests, they are actually integration tests used at the component building time.

Thanks!
Rajith


The importance of having unit test layer is you can validate any issue before it reaches the feature and bundle with the product. Once it bundles with the produce cost of fix is high. So the point of the unit test is eliminating that. 

So if you are talking about unit test, they must at least cover this aspect. Else forget this test layer and write end to end integration test using docker or what ever. But they are Integration tests and have the cost i mentioned above. 

Thank you,
Dharshana. 

On Fri, May 19, 2017 at 11:53 AM, Malaka Gangananda <[hidden email]> wrote:
Hi,

Actually  JavaDB do have network drivers [1].


Thanks,

On Fri, May 19, 2017 at 11:35 AM, Uvindra Dias Jayasinha <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Thanks,

On Fri, May 19, 2017 at 8:11 AM, Pamod Sylvester <[hidden email]> wrote:
(+) Adding @architecture

On Thu, May 18, 2017 at 11:34 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, May 18, 2017 at 10:39 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ?  


Thanks,
Pamod
--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Hasitha Abeykoon
Senior Software EngineerWSO2, Inc.; http://wso2.com




--
Thanks & Regards,

Fazlan Nazeem
Senior Software Engineer
WSO2 Inc
Mobile : <a href="tel:%2B94%20%280%29%20773%20451194" value="+94773451194" target="_blank">+94772338839



--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Manuri Amaya Perera
Software Engineer
WSO2 Inc.






--
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [hidden email]
P: <a href="tel:+94%2077%20754%202851" value="+94777542851" target="_blank">+94 777542851



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Pumudu Ruhunage
Software Engineer | WSO2 Inc



--
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: <a href="tel:+94%2071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Sanjiva Weerawarana, Ph.D.
Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
email: [hidden email]; office: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">(+1 650 745 4499 | +94  11 214 5345) x5700; cell: <a href="tel:+94%2077%20787%206880" value="+94777876880" target="_blank">+94 77 787 6880 | <a href="tel:(408)%20466-5099" value="+14084665099" target="_blank">+1 408 466 5099; voip: <a href="tel:(650)%20265-8311" value="+16502658311" target="_blank">+1 650 265 8311; twitter: @sanjiva
Lean . Enterprise . Middleware



--
Regards,
Uvindra

Mobile: 777733962

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Malaka. 
-- 
Malaka Gangananda - Software Engineer | WSO2
Mobile : <a href="tel:071%20356%204340" value="+94713564340" target="_blank">+94713564340

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Dharshana Warusavitharana
Associate Technical Lead
Fax :<a href="tel:+94%2011%202%20145300" value="+94112145300" target="_blank">+94 11 2145300 
cell : <a href="tel:+94%2077%20034%202233" value="+94770342233" target="_blank">+94770342233
bloghttp://dharshanaw.blogspot.com

lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Pumudu Ruhunage
Software Engineer | WSO2 Inc

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Uvindra

Mobile: 777733962

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture