GSOC 2017: Project Proposal
sandhya bankar
bankarsandhya512 at gmail.com
Mon Apr 3 15:21:34 UTC 2017
On Mon, Apr 3, 2017 at 8:32 PM, Eugene Syromiatnikov <esyr at redhat.com> wrote:
> On Mon, Apr 03, 2017 at 08:08:34PM +0530, sandhya bankar wrote:
>> Please review my proposal link for the project "Comprehensive test suite"
>>
>> https://docs.google.com/document/d/1RY5cdJGb0UVN-5q5imuwrcVnFRlVgM0Rx3okdrfkxTU/edit?usp=sharing
>
> Can you please provide information regarding the schedule? Do you have
> any specific ideas in regards of why coverage is not good even for parts
> of code for which tests do exist (like quotactl and DM ioctl or some
> other syscalls) and how to deal with it (will you try to deal with it
> and, if yes, how so)? What do you plan to implement in regards of
> catching behavioural changes (taking into account that all the patches
> introducing new functionality already require corresponding test coverage)?
The timeline for my project is given below and also edited in proposal doc:
Timeline for project :
1 week - getting the setup up done
1 week - reading documentation
2 weeks - Initial research and code understanding.
4 weeks - Code development
1 week - Test the changes
3 weeks - submitting patches upstream, and
making revisions to the patches as suggested by upstream developers.
https://docs.google.com/document/d/1RY5cdJGb0UVN-5q5imuwrcVnFRlVgM0Rx3okdrfkxTU/edit?usp=sharing
To deal with code coverage, I will run individual test cases to find
out why the coverage is below 100%.
I am sure after running each and every test cases i will come with new
test cases to increase the code coverage.
To add test cases for new functionality, I will understand first what
its use case, why it is implemented, what are the purpose, what its
input/output criteria and according to that I can make my finding and
understanding into test cases.
Thanks,
Sandhya
More information about the Strace-devel
mailing list