Re: Code coverage for client.net package

Hi, On Fri, Jul 6, 2012 at 12:45 PM, Knut Anders Hatlen wrote: > > Instead of copying code from PrepareStatementTest, I'm wondering if we > could rather reuse the code directly by tweaking PrepareStatementTest's > suite() method to run the test cases with a decorator that makes them > use pooled

Re: Code coverage for client.net package

Mohamed Nufail writes: > Hi, > > I moved onto implementing some tests for the client.am package. I > first tried to cover the LogicalPreparedStatement class. I'm still > working on it and uploaded the current version on the following link. > http://pastebin.com/w4JqSh5Z > > In writing the above t

Re: Code coverage for client.net package

Hi, I moved onto implementing some tests for the client.am package. I first tried to cover the LogicalPreparedStatement class. I'm still working on it and uploaded the current version on the following link. http://pastebin.com/w4JqSh5Z In writing the above test, I looked into the following tests

Re: Code coverage for client.net package

On 06/18/2012 11:22 AM, Katherine Marsden wrote: I believe with ProtocolTest the client is not invoked at all but rather replaces the client, so it can only be used to help cover server side code. Oh! Good catch, Kathey! Thanks for saving us from heading down a dead end. > I suppose some sim

Re: Code coverage for client.net package

On 6/17/2012 10:07 AM, Bryan Pendleton wrote: Hello Nufail, I think that these methods are going to be challenging to exercise, since they may only arise due to implementation errors in either the client or the server. We have a special test suite that we have used in the past to force the exe

Re: Code coverage for client.net package

On 6/17/2012 1:37 AM, Mohamed Nufail wrote: Hi, I looked into some methods with low coverage to get an idea as to how to invoke them through a test. First in case you have not been introduced to the amazing literary masterpiece and valuable sleep aid of the three volume 2000+ page DRDA stand

Re: Code coverage for client.net package

Hi, Thank you for the guidance. I will try running ProtocolTest and open JIRA issues and continue with your suggestions. Thanks, Nufail. On Sun, Jun 17, 2012 at 10:37 PM, Bryan Pendleton < bpendleton.de...@gmail.com> wrote: > I looked into some methods with low coverage to get an idea as to how

Re: Code coverage for client.net package

I looked into some methods with low coverage to get an idea as to how to invoke them through a test. parseSQLDCGRP (Sqlca [], int): intin NetConnectionReply This seems to be called through parseSQLDIAGGRP(Sqlca[] rowsetSqlca). But code coverage shows that it returns after executing followin

Re: Code coverage for client.net package

Hi, I looked into some methods with low coverage to get an idea as to how to invoke them through a test. parseSQLDCGRP (Sqlca [], int): intin NetConnectionReply This seems to be called through parseSQLDIAGGRP(Sqlca[] rowsetSqlca). But code coverage shows that it returns after executing follow

Re: Code coverage for client.net package

Bryan Pendleton writes: >> This looks like a great collection of methods to focus on. >> >> Actually what I meant to say was that these methods are not being >> called in anywhere. Code inspection from my IDE revealed that >> these methods are unused. So it might be possible to remove them. >

Re: Code coverage for client.net package

This looks like a great collection of methods to focus on. Actually what I meant to say was that these methods are not being called in anywhere. Code inspection from my IDE revealed that these methods are unused. So it might be possible to remove them. Even better! Although it is possible

Re: Code coverage for client.net package

On Mon, Jun 11, 2012 at 7:45 PM, Bryan Pendleton wrote: > > This looks like a great collection of methods to focus on. > Actually what I meant to say was that these methods are not being called in anywhere. Code inspection from my IDE revealed that these methods are unused. So it might be possib

Re: Code coverage for client.net package

On 06/11/2012 01:07 AM, Mohamed Nufail wrote: By analysing those classes, I found that the following methods have no usage at all. This looks like a great collection of methods to focus on. I suggest that you open a single JIRA, with a subject something like: Investigate Network Clie

Re: Code coverage for client.net package

Hi, Thank you everyone for the valuable suggestions. By analysing those classes, I found that the following methods have no usage at all. NetConnectionReply class verifyConnectReply(int codept) readDummyExchangeServerAttributes(Connection connection) checkRequiredObjects(boolean receivedFlag, bo

Re: Code coverage for client.net package

On 06/06/2012 04:10 AM, Knut Anders Hatlen wrote: One strategy may be to pick one piece of code that lacks coverage, and find the corresponding code on the server which sends that kind of data to the client. I think this is a good technique. I tried your suggested technique, looking at the DSC

Re: Code coverage for client.net package

I think that the class NetConnectionReply is a good one to investigate. From what I can see, there are a lot of coverage gaps in this class, at least according to http://dbtg.foundry.sun.com/derby/test/coverage/_files/3c.html I agree that the protocol errors are hard to test for, so it's easier

Re: Code coverage for client.net package

On 6/6/2012 4:10 AM, Knut Anders Hatlen wrote: However, it looks like a lot of the code is handling errors, many of them protocol errors (which would only happen if there's a bug in the server or the client) or very unlikely errors (like NetResultSetReply.parseCloseError() which is only called

Re: Code coverage for client.net package

Mohamed Nufail writes: > Hi, > > Next I will focus on NetConnectionReply, NetPackageReply and > NetResultSetReply classes of the client.net package which have low > code coverage. I will look into these classes to get a better > understanding of them. I would like to know any suggestions regardin

Re: Code coverage for client.net package

Hi, Next I will focus on NetConnectionReply, NetPackageReply and NetResultSetReply classes of the client.net package which have low code coverage. I will look into these classes to get a better understanding of them. I would like to know any suggestions regarding this. Thanks, Nufail. On Sun, Ma

Re: Code coverage for client.net package

I created a JIRA issue for this at https://issues.apache.org/jira/browse/DERBY-5786 Regards, Nufail. On Sat, May 26, 2012 at 10:03 PM, Mohamed Nufail wrote: > Will do that. Thanks. > > Nufail. > > > On Sat, May 26, 2012 at 8:21 PM, Bryan Pendleton < > bpendleton.de...@gmail.com> wrote: > >> So

Re: Code coverage for client.net package

Will do that. Thanks. Nufail. On Sat, May 26, 2012 at 8:21 PM, Bryan Pendleton wrote: > So making it a stand alone class and using it instead of InputStreamUtil >> and DynamicByteArrayOutputStream classes should solve >> the problem. Shall I continue with this solution? >> > > Sure! > > It soun

Re: Code coverage for client.net package

So making it a stand alone class and using it instead of InputStreamUtil and DynamicByteArrayOutputStream classes should solve the problem. Shall I continue with this solution? Sure! It sounds like the problem is well-enough defined at this point. I think the next thing you should do is to op

Re: Code coverage for client.net package

On Sat, May 26, 2012 at 1:42 AM, Knut Anders Hatlen wrote: > Mohamed Nufail writes: > > Hi Nufail, > > Thanks for sharing your analysis. > > I think you're right that the extra functionality provided by > PublicBufferOutputStream isn't needed for writeUDT() to function > correctly. > > One small

Re: Code coverage for client.net package

PublicBufferOutputStream.getBuffer() returns the buffer directly, whereas ByteArrayOutputStream.toByteArray() creates a copy of the internal buffer. So by using PublicBufferOutputStream we save one allocation of a byte array per write. That seems like a strong enough reason to favor PublicBuffer

Re: Code coverage for client.net package

Mohamed Nufail writes: > Hi, > > Going through the related Jira issue, I found that the changes have > been introduced to get proper functionality for UDTs in the network > client. The network client was required to behave similar to the > embedded client when the columns contain java objects. Fo

Re: Code coverage for client.net package

Hi, Going through the related Jira issue, I found that the changes have been introduced to get proper functionality for UDTs in the network client. The network client was required to behave similar to the embedded client when the columns contain java objects. For this reason, some of the functiona

Re: Code coverage for client.net package

Thank you. I will go through those and come up with a solution. regards, Nufail. On Wed, May 23, 2012 at 9:22 AM, Bryan Pendleton wrote: > If only such little functionality is utilized, having those two classes is >> a waste. The new solution sounds much better. >> >> So shall I proceed with th

Re: Code coverage for client.net package

If only such little functionality is utilized, having those two classes is a waste. The new solution sounds much better. So shall I proceed with the suggested solution? Yes, I think that would be great! As Knut Anders observed, these two classes were created fairly recently. You might start

Re: Code coverage for client.net package

+1 If only such little functionality is utilized, having those two classes is a waste. The new solution sounds much better. So shall I proceed with the suggested solution? Regards, Nufail. On Wed, May 23, 2012 at 5:22 AM, Bryan Pendleton wrote: > On 05/22/2012 07:51 AM, Knut Anders Hatlen wro

Re: Code coverage for client.net package

On 05/22/2012 07:51 AM, Knut Anders Hatlen wrote: I'm wondering if it would be more reasonable just to remove the two classes and make writeUDT() use either java.io.ByteArrayOutputStream or EncodedInputStream.PublicBufferOutputStream instead. The latter class already is in the client.net package,

Re: Code coverage for client.net package

Bryan Pendleton writes: >> First I will focus on the client.net package. In the >> schedule I mentioned that I would be looking into the >> InputStreamUtil and DynamicByteArrayOutputStream classes first, because I >> thought they would be easy to tackle with initially >> and

Re: Code coverage for client.net package

First I will focus on the client.net package. In the schedule I mentioned that I would be looking into the InputStreamUtil and DynamicByteArrayOutputStream classes first, because I thought they would be easy to tackle with initially and those two classes have the least covera