From Fedora Project Wiki
No edit summary
No edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
__NOTOC__
__NOTOC__


* Name: Abhishek Kumar Singh
* FAS Account: Abhisheksingh
* Fedora userpage:[https://fedoraproject.org/wiki/User:Abhisheksingh https://fedoraproject.org/wiki/User:Abhisheksingh]


<h3> Personal Details </h3>
<h3> Contact Details </h3>


----
----


<ul>
<ul>
<li> Name: Abhishek Kumar Singh</li>
<li> Freenode IRC Nick: kanha</li>
<li> Freenode IRC Nick: kanha</li>
<li> Mobile No: +91 8893839740</li>
<li> Mobile No: +91 8893839740</li>
Line 16: Line 18:


----
----
'''NOTE''': We require all students to blog about the progress of their project.
You are strongly encouraged to register on the Freenode network and participate
in our IRC channels. For more information and other instructions contact Org Admins.
''please answer following questions''


===Why do you want to work with the Fedora Project?===
===Why do you want to work with the Fedora Project?===


I am passionate about OSS(Open Source Software). During the initial phase of my contribution to [https://fedorahosted.org/sssd/ SSSD] I got a chance to play with Fedora 18 and I was impressed by it to such an extent that I am a Fedora user now. Fedora is really cool and an awesome OS with everything being so lucid, attractive and the last but not the least an impressive GUI. It will be give me immense pleasure contributing to the product which I admire most.
I am passionate about Open Source Software. During the initial phase of my contribution to [https://fedorahosted.org/sssd/ SSSD] I got a chance to play with Fedora 18 and I was impressed by it to such an extent that I am a Fedora user now. Fedora is really cool and an awesome OS with everything being so lucid, attractive and the last but not the least an impressive GUI. It will be a pleasure contributing to a project like Fedora.  


===Do you have any past involvement with the Fedora project or any other open source project as a contributor?===
===Do you have any past involvement with the Fedora project or any other open source project as a contributor?===


I have contributed to other open source project as well https://fedoraproject.org/wiki/User:Abhisheksingh/contributions .  
I have contributed to other open source projects as well https://fedoraproject.org/wiki/User:Abhisheksingh/contributions .  


===Did you participate with the past GSoC programs, if so which years, which organizations?===
===Did you participate with the past GSoC programs, if so which years, which organizations?===
Line 31: Line 39:
===Will you continue contributing/ supporting the Fedora project after the GSoC 2013 program, if yes, which team(s), you are interested with?===
===Will you continue contributing/ supporting the Fedora project after the GSoC 2013 program, if yes, which team(s), you are interested with?===


Yes, I will continue my support,contributions to Fedora project even after Gsoc 2013. I am interested in SSSD team and QA team.There are lots of opportunities for contribution with the release of SSSD 1.9.5 and focus on developing new features for upcoming SSSD 1.10.
Yes, I will continue my support, contributions to Fedora project even after Gsoc 2013. I am interested in SSSD team and QA team. There are lots of opportunities for contribution with the release of SSSD 1.9.5 and the upcoming new features in SSSD 1.10.
 
===Why should we choose you over other applicants?===
===Why should we choose you over other applicants?===


I have sound programming skills in C, C++ and Python. I have acquired good knowledge of cmocka framework and have done some initial contribution in support of my proposal. I am willing to contribute and support my project through out my lifetime, also I have keen interest in contributing to SSSD and QA community after GSoC 2013.    
I have sound programming skills in C, C++ and Python. I have acquired good knowledge of cmocka framework and have done some initial contribution in support of my proposal. I am willing to contribute and support my project after the GSoC program finishes, I also have keen interest in contributing to SSSD and the QA community after GSoC 2013.




Line 41: Line 49:


<h3> Introduction </h3>
<h3> Introduction </h3>
<p> An idea of implementing a battery of unit tests for [https://fedorahosted.org/sssd/ SSSD](System Service Security Daemon) using cmocka unit test framework is proposed after having a good discussion with jhrozek(Jakub Hrozek, #sssd). Actually, it is not just writing better automated test codes but a total refinement of SSSD unit-tests including cmocka unit testing framework in such a way that it will reduce complexity of code make it efficient and provide a good mocking framework for better testing. Following are the details of the project and the proposed plan of action. </p>
<p> An idea of implementing a battery of unit tests for [https://fedorahosted.org/sssd/ SSSD](System Service Security Daemon) using cmocka unit test framework is proposed after having a thorough discussion with the SSSD upstream maintainer jhrozek (Jakub Hrozek, #sssd). Actually, it is not just writing better automated test codes but a total refinement of SSSD unit-tests using the cmocka unit testing framework in such a way that it will reduce complexity of unit testing code and making it efficient and provide a good mocking framework for better testing for other developers. Following are the details of the project and the proposed plan of action. </p>


<h3> Abstract </h3>
<h3> Abstract </h3>
<p> Implementing unit tests for SSSD modules using cmocka unit testing framework with proper refactoring, minimum boilerplates and better test coverage. Doing sanity checking, resulting in efficient test codes.</p>
<p> Implementing unit tests for SSSD modules using cmocka unit testing framework with proper refactoring, minimum boilerplates and better test coverage. The tests would focus on both covering the new features but mostly on creating test for the core SSSD features, providing developers with better confidence when writing new code</p>


<h3> Benefits to Fedora community </h3>
<h3> Benefits to Fedora community </h3>
Line 50: Line 58:
<ul>
<ul>
<li> Contributing the set of unit tests to the SSSD would greatly improve its stability long-term and would help raise confidence when pushing new SSSD versions into Fedora or other distributions.</li>
<li> Contributing the set of unit tests to the SSSD would greatly improve its stability long-term and would help raise confidence when pushing new SSSD versions into Fedora or other distributions.</li>
<li> Making SSSD tests less complicated and mocking based Unittesting framework would certainly result into an improved testing mechanism and error handling in SSSD. </li>
<li> Making SSSD tests less complicated and mock-based unittesting framework would certainly result into an improved testing mechanism and error handling in SSSD. </li>
<li> Improvement in the test coverage will result in improvement of code quality of mozbase. </li>
<li> Improvement in the test coverage will result in improvement of code quality of the SSSD. </li>
<li> Writing unit-test will help in deep extensibilty to the behaviour of SSSD code and eventually results in solving many of the issuses related to SSSD-testing on bug tracker</li>
<li> Writing unit-test will help in deeper confidence in the correct behaviour of SSSD code and eventually result in easier resolution of many of the issuses related to SSSD</li>
</ul>
</ul>


<h3> Project Details </h3>
<h3> Project Details </h3>


<p> The aim of the project is not just quality assurance of SSSD but to provide a proper implementation of a Unit testing framework rather than just a POC(proof of concept). It has far greater goals. SSSD is so important that all of Linux based operating systems uses it including Fedora and others. But the Current version of SSSD lacks proper unit testing framework for exercising the code which are only reachable when SSSD is connected to the network. This project deals more about writing new efficient cmocka based tests and complete refinement of old written SSSD tests using cmocka framework. The idea here is to dig deeper into testing to provide and maintain long-term robustness and quality of SSSD. It is also important that the new cmocka based tests should be less complex and more efficient. It should have more automated behavior and minimum or no boilerplate. It should also follow proper coding styles followed by SSSD. </p>
<p> The aim of the project is not just quality assurance of SSSD but to provide a proper implementation of a Unit testing framework rather than just a proof-of-concept. It has far greater goals. SSSD is an important part of the authentication picture for Fedora and other Linux distributions. Unfortunately the current version of SSSD lacks proper unit testing framework for exercising the code which are only reachable when SSSD is connected to the network. This project deals more about writing new tests based on the cmocka framweork and complete refinement of old written SSSD tests using the check framework. The idea here is to dig deeper into testing to provide and maintain long-term robustness and quality of SSSD. It is also important that the new cmocka based tests should be less complex and more efficient. It should have more automated behavior and minimum or no boilerplate code. It should also the coding style set by SSSD coding guidelines. </p>


<p> One other feature of the framework should be that it should be sustainable and support further improvements. It means that if the tests need to be implemented further because of addition or enhancement of new feature(s) or tests need to be modified after a year or something, only slight change in the fixers should be enough and an automated process would be taking care of implementation of respective fixers to the tests. Since, it would be quite troublesome to implement all the tests again and again with each new modification or new release of SSSD dependencies, this feature is quite necessary from development perspective. </p>
<p> The other important feature of the framework should be that it should
be sustainable long-term in order to support further SSSD improvements.  
In other words, the tests must be easy to modify when the core SSSD code changes to minimize the time needed to fix the unit tests after architectural changes are performed to the SSSD. This feature would allow the SSSD developers to be more confident of refactoring changes in the daemon itself. </p>


====Tools Required During Development====
====Tools Required During Development====


<ul>
<ul>
<li> Talloc and Tevent</li>
<li> the Talloc and Tevent libraries</li>
<li> Cmocka library </li>
<li> Cmocka library </li>
<li> Coverage tool : lcov </li>
<li> Coverage tool : lcov </li>
Line 77: Line 87:
The general idea for the unit tests is to cover the two most important parts:
The general idea for the unit tests is to cover the two most important parts:
<ul>
<ul>
<li> getting user information </li>  
<li> retrieving user information </li>  
<li> authenticating users. </li>
<li> authenticating users. </li>
</ul>
</ul>


So, basically the whole project is divided into two phases:
The following diagram gives a pictorial representation of the core components of SSSD and how they interact.
[[File:Sssdsoc.png]]
 
 
Basically the whole project is divided into two phases, which mimick how the SSSD itself is structured:
<ul>
<ul>
<li> '''Phase I''' : building provider tests
<li> '''Phase I''' : building provider tests
Line 87: Line 101:
</ul>
</ul>
   
   
The unit tests would cover the NSS and PAM responders. The back end tests would cover the LDAP users and group code. These are the most important parts of the SSSD thus focus will be mainly on providing good tests for them.
Because of the large size of the SSSD project, the unit testing framework would focus on the core SSSD features that are enabled in most, if not all, SSSD deployments.
In particular, the unit tests would cover only the NSS and PAM responders, while the back end (provider) tests would cover the LDAP users and group code.


<h3>Time-line for Milestones</h3>
<h3>Time-line for Milestones</h3>
Line 93: Line 108:
The project is planned to be split across following weekly phases:  
The project is planned to be split across following weekly phases:  


'''[Test Week 1]'''
'''[Project Week 1]'''


Learning the tevent library and the async model
Learning the tevent library and the asynchronous model


'''[Test Week 2]'''   
'''[Project Week 2]'''   


Learning the tevent library and the async model. Might include some experimenting and reading the code.
Learning the tevent library and the async model. Might include some experimenting and reading the code.


'''[Test Week 3]'''  
'''[Project Week 3]'''  


Reading the current NSS responder test and augmenting the "get user by XXX tests"
Reading the current NSS responder test and augmenting the "get user by name/ID tests"


'''[Test Week 4]'''  
'''[Project Week 4]'''  


Adding a similar test for retrieving groups as added for users in the previous step
Adding a similar test for retrieving groups as added for users in the previous step.


'''[Test Week 5]'''
'''[Project Week 5]'''


Adding another test for the initgroups operation
Adding another test for the initgroups operation.


'''[Test Week 6]'''   
'''[Project Week 6]'''   


Studying the PAM responder code.
Studying the PAM responder code.


'''[Test Week 7]'''
'''[Project Week 7]'''


Add a unit test that would cover the PAM responder. Only login(auth phase) can be covered.
Adding a unit test that would cover the PAM responder. Only login (PAM authentication phase) can be covered.


'''[Test Week 8]'''   
'''[Project Week 8]'''   


Learning the backend and provider internals. The current DNS update tests might be a good start.
Learning the backend and provider internals. The current DNS update tests might be a good start.


'''[Test Week 9]'''
'''[Project Week 9]'''


Creating unit tests for retrieving LDAP users. These tests would not be big by themselves, but would include code to be reused by other LDAP tests later
Creating unit tests for retrieving LDAP users. These tests would not be big by themselves, but would include code to be reused by other LDAP tests later


'''[Test Week 10]'''  
'''[Project Week 10]'''  


Creating unit tests for storing LDAP groups without nesting RFC2307)
Creating unit tests for storing LDAP groups without nesting (RFC2307)


'''[Test Week 11]'''
'''[Project Week 11]'''


Creating unit tests for storing LDAP groups with nesting(RFC2307bis)
Creating unit tests for storing LDAP groups with nesting (RFC2307bis)


'''[Test Week 12]'''
'''[Project Week 12]'''


An extra week to polish the work before submission
An extra week to polish the work before submission
Line 146: Line 161:
<ul>
<ul>
<li> Tests covering NSS and PAM responders </li>
<li> Tests covering NSS and PAM responders </li>
<li>clean codes by uncovering major issues </li>
<li>Contribute to the overall
code quality by uncovering issues with the unit tests </li>


<li>Less complex test infrastructure </li>
<li>Less complex test infrastructure </li>
Line 155: Line 171:
=== Have you communicated with a potential mentor?  If so, who? ===
=== Have you communicated with a potential mentor?  If so, who? ===


Yes, I am in touch with Jakub Hrozek(jhrozek, #sssd) for quite long time.
Yes, I am in touch with Jakub Hrozek (jhrozek, #sssd) for quite long time.

Latest revision as of 05:32, 4 May 2013


Contact Details

NOTE: We require all students to blog about the progress of their project. You are strongly encouraged to register on the Freenode network and participate in our IRC channels. For more information and other instructions contact Org Admins.

please answer following questions

Why do you want to work with the Fedora Project?

I am passionate about Open Source Software. During the initial phase of my contribution to SSSD I got a chance to play with Fedora 18 and I was impressed by it to such an extent that I am a Fedora user now. Fedora is really cool and an awesome OS with everything being so lucid, attractive and the last but not the least an impressive GUI. It will be a pleasure contributing to a project like Fedora.

Do you have any past involvement with the Fedora project or any other open source project as a contributor?

I have contributed to other open source projects as well https://fedoraproject.org/wiki/User:Abhisheksingh/contributions .

Did you participate with the past GSoC programs, if so which years, which organizations?

No

Will you continue contributing/ supporting the Fedora project after the GSoC 2013 program, if yes, which team(s), you are interested with?

Yes, I will continue my support, contributions to Fedora project even after Gsoc 2013. I am interested in SSSD team and QA team. There are lots of opportunities for contribution with the release of SSSD 1.9.5 and the upcoming new features in SSSD 1.10.

Why should we choose you over other applicants?

I have sound programming skills in C, C++ and Python. I have acquired good knowledge of cmocka framework and have done some initial contribution in support of my proposal. I am willing to contribute and support my project after the GSoC program finishes, I also have keen interest in contributing to SSSD and the QA community after GSoC 2013.


Implement a battery of unit tests for SSSD

Introduction

An idea of implementing a battery of unit tests for SSSD(System Service Security Daemon) using cmocka unit test framework is proposed after having a thorough discussion with the SSSD upstream maintainer jhrozek (Jakub Hrozek, #sssd). Actually, it is not just writing better automated test codes but a total refinement of SSSD unit-tests using the cmocka unit testing framework in such a way that it will reduce complexity of unit testing code and making it efficient and provide a good mocking framework for better testing for other developers. Following are the details of the project and the proposed plan of action.

Abstract

Implementing unit tests for SSSD modules using cmocka unit testing framework with proper refactoring, minimum boilerplates and better test coverage. The tests would focus on both covering the new features but mostly on creating test for the core SSSD features, providing developers with better confidence when writing new code

Benefits to Fedora community

  • Contributing the set of unit tests to the SSSD would greatly improve its stability long-term and would help raise confidence when pushing new SSSD versions into Fedora or other distributions.
  • Making SSSD tests less complicated and mock-based unittesting framework would certainly result into an improved testing mechanism and error handling in SSSD.
  • Improvement in the test coverage will result in improvement of code quality of the SSSD.
  • Writing unit-test will help in deeper confidence in the correct behaviour of SSSD code and eventually result in easier resolution of many of the issuses related to SSSD

Project Details

The aim of the project is not just quality assurance of SSSD but to provide a proper implementation of a Unit testing framework rather than just a proof-of-concept. It has far greater goals. SSSD is an important part of the authentication picture for Fedora and other Linux distributions. Unfortunately the current version of SSSD lacks proper unit testing framework for exercising the code which are only reachable when SSSD is connected to the network. This project deals more about writing new tests based on the cmocka framweork and complete refinement of old written SSSD tests using the check framework. The idea here is to dig deeper into testing to provide and maintain long-term robustness and quality of SSSD. It is also important that the new cmocka based tests should be less complex and more efficient. It should have more automated behavior and minimum or no boilerplate code. It should also the coding style set by SSSD coding guidelines.

The other important feature of the framework should be that it should be sustainable long-term in order to support further SSSD improvements. In other words, the tests must be easy to modify when the core SSSD code changes to minimize the time needed to fix the unit tests after architectural changes are performed to the SSSD. This feature would allow the SSSD developers to be more confident of refactoring changes in the daemon itself.

Tools Required During Development

  • the Talloc and Tevent libraries
  • Cmocka library
  • Coverage tool : lcov
  • Vim (IDE)


The outline of my work plans

The initial stage of my work deals with becoming familiar with SSSD and learning concepts of cmocka unit-testing framework as mentioned in plan.

The general idea for the unit tests is to cover the two most important parts:

  • retrieving user information
  • authenticating users.

The following diagram gives a pictorial representation of the core components of SSSD and how they interact. Sssdsoc.png


Basically the whole project is divided into two phases, which mimick how the SSSD itself is structured:

  • Phase I : building provider tests
  • Phase II: building responder tests

Because of the large size of the SSSD project, the unit testing framework would focus on the core SSSD features that are enabled in most, if not all, SSSD deployments. In particular, the unit tests would cover only the NSS and PAM responders, while the back end (provider) tests would cover the LDAP users and group code.

Time-line for Milestones

The project is planned to be split across following weekly phases:

[Project Week 1]

Learning the tevent library and the asynchronous model

[Project Week 2]

Learning the tevent library and the async model. Might include some experimenting and reading the code.

[Project Week 3]

Reading the current NSS responder test and augmenting the "get user by name/ID tests"

[Project Week 4]

Adding a similar test for retrieving groups as added for users in the previous step.

[Project Week 5]

Adding another test for the initgroups operation.

[Project Week 6]

Studying the PAM responder code.

[Project Week 7]

Adding a unit test that would cover the PAM responder. Only login (PAM authentication phase) can be covered.

[Project Week 8]

Learning the backend and provider internals. The current DNS update tests might be a good start.

[Project Week 9]

Creating unit tests for retrieving LDAP users. These tests would not be big by themselves, but would include code to be reused by other LDAP tests later

[Project Week 10]

Creating unit tests for storing LDAP groups without nesting (RFC2307)

[Project Week 11]

Creating unit tests for storing LDAP groups with nesting (RFC2307bis)

[Project Week 12]

An extra week to polish the work before submission

Deliverables

Better and improved test codes of SSSD with following features:

  • Tests covering NSS and PAM responders
  • Contribute to the overall code quality by uncovering issues with the unit tests
  • Less complex test infrastructure
  • More efficient testing mechanism

Have you communicated with a potential mentor? If so, who?

Yes, I am in touch with Jakub Hrozek (jhrozek, #sssd) for quite long time.

Retrieved from "https://fedoraproject.org/w/index.php?title=User:Abhisheksingh/Gsoc2013Proposal&oldid=335381"