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