tests and coverage

[Justin Mclean <ju...@classsoftware.com>]

Hi,

It looks to me that some of the tests are just here to increase coverage and we seem to be missing unit test for some of the more simple classes. Perhaps there’s a bit too much focus on the happy path and we’re not always checking boundary conditions and the like. Obviously this is a good start but do you think we can improve on this?

I just checked in some tests for ByteValue and you note that one of the tests is failing due to a (minor) issue in the code. It's easily fixed but I think it illustrates the point that this sort of mistake is easy to make and easy to find via unit tests. There’s no finger of blame here, I make those sort of mistakes (and more) as well. Even more reason to have tests :-)

Thanks,
Justin

Re: tests and coverage

[Justin Mclean <ju...@me.com>]

Hi,

> I  don’t think its a issue of focus rather than time and resources (at least in my case)

Fair enough and as I said we have tests (with reasonable coverage) and that's a good thing.

> My intention was to bring the ADS branch to master a soon as possible to encourage contribution (seems like it worked very well :o).

:-)

> So I would suggest to either make an „TODO: Test {concrete test case}“ in the main code or implement a failing or ignored test in the Test-Classes which makes clear what Tests are missing. This way we don’t oversee stuff that still needs testing. What do you think?

Sounds like a great idea to me.

Thanks,
Justin

Re: tests and coverage

[Sebastian Rühl <se...@googlemail.com>]

Hi Justin,

First of all thanks for the Tests (and finding the Bug :). You are absolutely right about your statements but I don’t think its a issue of focus rather than time and resources (at least in my case). My intention was to bring the ADS branch to master a soon as possible to encourage contribution (seems like it worked very well :o). But maybe we need a marker to indicate that we need more testing (for example with the boundaries I was aware of but didn’t have time to implement them). So I would suggest to either make an „TODO: Test {concrete test case}“ in the main code or implement a failing or ignored test in the Test-Classes which makes clear what Tests are missing. This way we don’t oversee stuff that still needs testing. What do you think?

No offense taken and thanks again for pointing this out. :)

Sebastian

> Am 20.02.2018 um 03:31 schrieb Justin Mclean <ju...@classsoftware.com>:
> 
> Hi,
> 
> It looks to me that some of the tests are just here to increase coverage and we seem to be missing unit test for some of the more simple classes. Perhaps there’s a bit too much focus on the happy path and we’re not always checking boundary conditions and the like. Obviously this is a good start but do you think we can improve on this?
> 
> I just checked in some tests for ByteValue and you note that one of the tests is failing due to a (minor) issue in the code. It's easily fixed but I think it illustrates the point that this sort of mistake is easy to make and easy to find via unit tests. There’s no finger of blame here, I make those sort of mistakes (and more) as well. Even more reason to have tests :-)
> 
> Thanks,
> Justin

Re: tests and coverage

[Christofer Dutz <ch...@c-ware.de>]

I definitely agree that every test in every project can be improved. The tests we have now did bring up several issues, but I do agree that we will have to bring in more side path tests. I am hoping that with the integration test framework I'm working on, it will be easier to provide such tests without having to strain your brain too much.

Chris

Outlook for Android<https://aka.ms/ghei36> herunterladen

________________________________
From: Justin Mclean <ju...@classsoftware.com>
Sent: Tuesday, February 20, 2018 3:31:15 AM
To: dev@plc4x.apache.org
Subject: tests and coverage

Hi,

It looks to me that some of the tests are just here to increase coverage and we seem to be missing unit test for some of the more simple classes. Perhaps there’s a bit too much focus on the happy path and we’re not always checking boundary conditions and the like. Obviously this is a good start but do you think we can improve on this?

I just checked in some tests for ByteValue and you note that one of the tests is failing due to a (minor) issue in the code. It's easily fixed but I think it illustrates the point that this sort of mistake is easy to make and easy to find via unit tests. There’s no finger of blame here, I make those sort of mistakes (and more) as well. Even more reason to have tests :-)

Thanks,
Justin