Thanks for your reply, Dieter

I will dig into the information that you gave me deeper.

I am very familiar with the CI env and PHP code coverage, because I just finished a similiar project when I Intern on Yahoo! last year.

when I intern on Yahoo! last year, I finished a automatic testing job: 1. PHP UNIT code and Functional testing code. 2. Commit to SVN will trigger a CI build. 3. The CI build is done by: slenium + Firefox+ Xvfb (so that we dont need screen) 4. output the code coverage report.

adam

From: Dieter Adriaenssens Date: 2013-03-19 17:49 To: adamgsoc2013; phpmyadmin-devel Subject: Re: [Phpmyadmin-devel] new here for GSOC 2013/3/19 adam adamgsoc2013@gmail.com:

Hi All,

I am new here for GSOC. After reading the idea listed on link: https://wiki.phpmyadmin.net/pma/GSoC_2013_Ideas_List#Automated_testing

I am quite interested on the topic: Automatic testing. I have some developing experience on selenium and PHP Code Coverage.

I am very glad to join phpmyadmin. I will dig my selves into here, thanks

---

adam

Hi,

If you are interested in applying for a GSoC project, you can take a look at our applicant guide [0], it will tell you what we expect from applicants. In case of the automated testing idea : A good way to start is to have a look at the current tests [1] and code coverage [2]. We expect you to provide a patch as part of your project proposal, so you can add a few tests to show us that you understand the code.

[0] http://wiki.phpmyadmin.net/pma/GSoC_2013_Applicant_Guide [1] http://wiki.phpmyadmin.net/pma/Unit_Testing [2] http://ci.phpmyadmin.net/job/phpMyAdmin/cloverphp

Hi,

I have more thinkings on the Phpmyadmin Automatic testing after reading more codes. ========================Code Learning==================== Following is my code learning: in the index.php page, PMA will display all the links for users. the links can be some types: 1. for server operation: server_<operation>.php (ig: server_databases.php) 2. for batabase operation: db_<operation>.php (ig: db_events.php ) 3. for table operation: tbl_<operation>..php (ig: tbl_replace.php ) .................

========================workflow==================== take "server_databases.php" for example. it is for user to create or drop database.

in the server_databases.php, the file will include: 1. "server_databases.js" in JS folder, it is for Ajax request to backend. 2. "display_create_database.lib.php " it is output the page element for create table. including action tag for ajax request. 3. when user clicks the "create", there will be a ajax request to db_create.php 4. in db_create.php, the SQL is executed and return the execute result to frontend. 5. the frontend page use the Ajax request and refresh the page.

that is the simple process for every user operation.

====================my confusion================ back to my project: Automatic testing . Following is my confusion: 1. why the db_create.php and some php page is stored on ROOT folder instead of libary folder? Is it because it for browser access? a link? 2. From the code coverage report page: http://ci.phpmyadmin.net/job/phpMyAdmin%203.5/cloverphp/? I found that a lot of file is not included. such as the php file on the ROOT folder.

Can someone give me some tips? thanks, I am looking forward to hearing your reply. thanks

But the way, I try to pick up and fix some bugs on: http://sourceforge.net/p/phpmyadmin/bugs/

adam

From: adam Date: 2013-03-21 00:40 To: Dieter Adriaenssens; phpmyadmin-devel Subject: about project: Automatic testing Thanks for your reply, Dieter

I will dig into the information that you gave me deeper.

I am very familiar with the CI env and PHP code coverage, because I just finished a similiar project when I Intern on Yahoo! last year.

when I intern on Yahoo! last year, I finished a automatic testing job: 1. PHP UNIT code and Functional testing code. 2. Commit to SVN will trigger a CI build. 3. The CI build is done by: slenium + Firefox+ Xvfb (so that we dont need screen) 4. output the code coverage report.

adam

From: Dieter Adriaenssens Date: 2013-03-19 17:49 To: adamgsoc2013; phpmyadmin-devel Subject: Re: [Phpmyadmin-devel] new here for GSOC 2013/3/19 adam adamgsoc2013@gmail.com:

Hi All,

I am new here for GSOC. After reading the idea listed on link: https://wiki.phpmyadmin.net/pma/GSoC_2013_Ideas_List#Automated_testing

I am quite interested on the topic: Automatic testing. I have some developing experience on selenium and PHP Code Coverage.

I am very glad to join phpmyadmin. I will dig my selves into here, thanks

---

adam

Hi,

If you are interested in applying for a GSoC project, you can take a look at our applicant guide [0], it will tell you what we expect from applicants. In case of the automated testing idea : A good way to start is to have a look at the current tests [1] and code coverage [2]. We expect you to provide a patch as part of your project proposal, so you can add a few tests to show us that you understand the code.

[0] http://wiki.phpmyadmin.net/pma/GSoC_2013_Applicant_Guide [1] http://wiki.phpmyadmin.net/pma/Unit_Testing [2] http://ci.phpmyadmin.net/job/phpMyAdmin/cloverphp

thanks MichalČihař,

You don't have to learn everything from the code, we have much of that documented: http://wiki.phpmyadmin.net/pma/Development

Yes, I am setting up the CI env on my dev box. after that, I can run the test report on my dev box, so that I can manager everything before checking code.

Because they are not run in any testcase and they are not included in coverage report because of that.

right, we should increase the code coverage of Backend class since there are logic related. and the render php may be changed easily.

thanks,

adam

From: MichalČihař Date: 2013-03-25 17:54 To: phpmyadmin-devel Subject: Re: [Phpmyadmin-devel] Automatic testing Hi

first of all it is not needed to CC all my emails, using mailing list is enough :-).

Dne Sat, 23 Mar 2013 18:18:36 +0800 adam adamgsoc2013@gmail.com napsal(a):

I have more thinkings on the Phpmyadmin Automatic testing after reading more codes. ========================Code Learning==================== Following is my code learning:

You don't have to learn everything from the code, we have much of that documented:

http://wiki.phpmyadmin.net/pma/Development

1. why the db_create.php and some php page is stored on ROOT folder instead of libary folder? Is it because it for browser access? a link?

Yes for links and for backward compatibility with non AJAX versions.

2. From the code coverage report page: http://ci.phpmyadmin.net/job/phpMyAdmin%203.5/cloverphp/?

I found that a lot of file is not included. such as the php file on the ROOT folder.

Because they are not run in any testcase and they are not included in coverage report because of that.

About the topic, at least two things should be done:

1. create more test cases to increase the code-coverage of the test-suite

From the following data, Total48.55%11386 / 2345248.04%368 / 76615.79%9 / 57 libraries47.45%10894 / 2296048.04%368 / 76615.79%9 / 57

Yes, that's one of the goals for this GSoC project.

2. set up the necessary scripts to automate this.

https://github.com/adamgsoc2013/phpmyadmin/tree/master/scripts

Pretty much everything about testing is automated in build.xml in project root.

2013/3/29 adam adamgsoc2013@gmail.com:

Hi,

Firstly, we use bottom-posting on this mailing list. [2]

I have a question about current Automatic testing process. When one guy finished a piece of code on the library folder about the Backend logic.

Should he follows some instructions before check in code besides Code-review?

1. UT implementation
2. Regression --> this will be checked by CI Job
3. running regression and UT on his dev box?

What do you mean by regression tests? How are they different from unit tests? The process you describe sounds reasonable. If you rearrange the order a bit, and add codechecking to your process, you are on your way of writing good code (see below for suggestions)

In my mind, the fomal processes should be:

1. add UT code

(TDD [0] principle, write tests first, then start implementing the class/method)

2. add logic code

3. test on dev box
4. run UT & regression test on dev box
5. code review after pass 1-4

-> check coding style compliance, with PHP_CodeSniffer and fix the reported issues. You can run Jenkins on your own box, or execute `phpcs filename` on the command line, more info on setting up Jenkins [1]

6. checkin code
7. check CI build

.....

[0] https://en.wikipedia.org/wiki/Test-driven_development [1] http://wiki.phpmyadmin.net/pma/Jenkins_Setup [2] https://en.wikipedia.org/wiki/Posting_style#Bottom-posting

2013/3/29 adam adamgsoc2013@gmail.com:

Hi Dieter,

thanks for your reply. I was trying to apply the GSOC topic: Automatic testing. so I want to check with you guys about the fomal process

...

What do you mean by regression tests? How are they different from unit tests? The process you describe sounds reasonable. If you rearrange the order a bit, and add codechecking to your process, you are on your way of writing good code (see below for suggestions)

In my mind, the regression tests is different from the unit tests. or in other word, we can say that the regression test include Unit tests. the regression test can include function test case beside unit tests.

In my mind, in order to gurantee the code quality, UNIT test just cover the code logic, but Fuinctional test can be end to end case with real case.

Ok, makes sense. How do you plan to automate the functional tests?

...

In my mind, the fomal processes should be:

1. add UT code

(TDD [0] principle, write tests first, then start implementing the class/method) 2. add logic code 3. test on dev box 4. run UT & regression test on dev box 5. code review after pass 1-4

...

-> check coding style compliance, with PHP_CodeSniffer and fix the reported issues. You can run Jenkins on your own box, or execute `phpcs filename` on the command line, more info on setting up Jenkins [1]

...

...

6. checkin code
7. check CI build

.....

I agree with you. so the process should be:

1. Add UT code
2. Add logic code
3. test on dev box
4. run UT & regression test on dev box
5. check coding style compliance, with PHP_CodeSniffer <---- I think we

should do it before code-review

I meant it to be part of the code reviewing. ;)

6. code review

-> 6.a run UT & regression test on dev box

best to test everything again after code reviewing and before commiting and checking in code.

7 checkin code 8 check CI build result

thanks,

Adam

2013/3/31 adam adam adamgsoc2013@gmail.com

Hi,

I also spent some time to think about the functional test case as well. ( I think this can be one part of the GSOC topic Automatic testing as well.)

...

How do you plan to automate the functional tests?

I think Selenium can cover Functional case as well. take index.php for example, we can use Selenium to load the index.php, and check the page element, such as <mainFrameset> and <frame_navigation>

Sure. Just consider that some things are not outputted to the browser, like exporting and importing.

in other word, we can use selenium to check Page element is loaded correctly, I think this work is as important as Unit test.

other benefit, we can cover phpmyadmin can work well one GradeA browsers.

1. check the page is loaded correctly
2. check the page is working well on GradeA browsers.
3. check the css/js is working well

......

...

5. check coding style compliance, with PHP_CodeSniffer <---- I think we

should do it before code-review

...

I meant it to be part of the code reviewing. ;)

...

6. code review

...

-> 6.a run UT & regression test on dev box

...

best to test everything again after code reviewing and before commiting and checking in code.

...

7 checkin code 8 check CI build result

totally agree, codesniffer can be one part of CI job, if the codesniffer failed, the CI should failed as well.

Codesniffer is already a part of CI (see Jenkins reports [0]). I meant that you should check your coding style of the changes you made, before commiting.

[0] http://ci.phpmyadmin.net/job/phpMyAdmin/

thanks,

Adam

On Fri, Mar 29, 2013 at 6:41 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:

...

2013/3/29 adam adamgsoc2013@gmail.com:

...

Hi Dieter,

thanks for your reply. I was trying to apply the GSOC topic: Automatic testing. so I want to check with you guys about the fomal process

...

What do you mean by regression tests? How are they different from unit tests? The process you describe sounds reasonable. If you rearrange the order a bit, and add codechecking to your process, you are on your way of writing good code (see below for suggestions)

In my mind, the regression tests is different from the unit tests. or in other word, we can say that the regression test include Unit tests. the regression test can include function test case beside unit tests.

In my mind, in order to gurantee the code quality, UNIT test just cover the code logic, but Fuinctional test can be end to end case with real case.

Ok, makes sense. How do you plan to automate the functional tests?

...

...

In my mind, the fomal processes should be:

1. add UT code

(TDD [0] principle, write tests first, then start implementing the class/method) 2. add logic code 3. test on dev box 4. run UT & regression test on dev box 5. code review after pass 1-4

...

-> check coding style compliance, with PHP_CodeSniffer and fix the reported issues. You can run Jenkins on your own box, or execute `phpcs filename` on the command line, more info on setting up Jenkins [1]

...

...

6. checkin code
7. check CI build

.....

I agree with you. so the process should be:

1. Add UT code
2. Add logic code
3. test on dev box
4. run UT & regression test on dev box
5. check coding style compliance, with PHP_CodeSniffer <---- I think we

should do it before code-review

I meant it to be part of the code reviewing. ;)

...

6. code review

-> 6.a run UT & regression test on dev box

best to test everything again after code reviewing and before commiting and checking in code.

...

7 checkin code 8 check CI build result

...

thanks,

Adam

-- Kind regards,

Dieter Adriaenssens

-- Kind regards,

Dieter Adriaenssens

from our code view:

1. ROOT folder: there are files about the display and links in the index.php page, PMA will display all the links for users. the links can be some types: 1. for server operation: server_<operation>.php (ig: server_databases.php) 2. for batabase operation: db_<operation>.php (ig: db_events.php ) 3. for table operation: tbl_<operation>..php (ig: tbl_replace.php )

this files are not covered by Unit test, so we can use Selenium with Page element checking to cover them (Functional case)

2. For the Library folder, there are backend logic, it is suitable to use UNIT test to cover.

adam

From: adam Date: 2013-04-01 14:55 To: Dieter Adriaenssens CC: phpmyadmin-devel Subject: Re: Re: [Phpmyadmin-devel] Automatic testing Hi,

Just consider that some things are not outputted to the browser, like exporting and importing.

In my mind, selenium lite version can't acchive this target, but we can use WebDriver to cover this situation. It is not the most important case in our testing, use page checking ,we can cover 90% important functional case.

I will try to cover some important functional case besides Unit testing when doing the GSOC project: Automatic testing

Thanks

adam

From: Dieter Adriaenssens Date: 2013-03-31 23:55 To: adam adam CC: phpmyadmin-devel Subject: Re: Re: [Phpmyadmin-devel] Automatic testing 2013/3/31 adam adam adamgsoc2013@gmail.com

Hi,

I also spent some time to think about the functional test case as well. ( I think this can be one part of the GSOC topic Automatic testing as well.)

...

How do you plan to automate the functional tests?

I think Selenium can cover Functional case as well. take index.php for example, we can use Selenium to load the index.php, and check the page element, such as <mainFrameset> and <frame_navigation>

Sure. Just consider that some things are not outputted to the browser, like exporting and importing.

in other word, we can use selenium to check Page element is loaded correctly, I think this work is as important as Unit test.

other benefit, we can cover phpmyadmin can work well one GradeA browsers.

1. check the page is loaded correctly
2. check the page is working well on GradeA browsers.
3. check the css/js is working well

......

...

5. check coding style compliance, with PHP_CodeSniffer <---- I think we

should do it before code-review

...

I meant it to be part of the code reviewing. ;)

...

6. code review

...

-> 6.a run UT & regression test on dev box

...

best to test everything again after code reviewing and before commiting and checking in code.

...

7 checkin code 8 check CI build result

totally agree, codesniffer can be one part of CI job, if the codesniffer failed, the CI should failed as well.

Codesniffer is already a part of CI (see Jenkins reports [0]). I meant that you should check your coding style of the changes you made, before commiting.

[0] http://ci.phpmyadmin.net/job/phpMyAdmin/

thanks,

Adam

On Fri, Mar 29, 2013 at 6:41 PM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:

...

2013/3/29 adam adamgsoc2013@gmail.com:

...

Hi Dieter,

thanks for your reply. I was trying to apply the GSOC topic: Automatic testing. so I want to check with you guys about the fomal process

...

What do you mean by regression tests? How are they different from unit tests? The process you describe sounds reasonable. If you rearrange the order a bit, and add codechecking to your process, you are on your way of writing good code (see below for suggestions)

In my mind, the regression tests is different from the unit tests. or in other word, we can say that the regression test include Unit tests. the regression test can include function test case beside unit tests.

In my mind, in order to gurantee the code quality, UNIT test just cover the code logic, but Fuinctional test can be end to end case with real case.

Ok, makes sense. How do you plan to automate the functional tests?

...

...

In my mind, the fomal processes should be:

1. add UT code

(TDD [0] principle, write tests first, then start implementing the class/method) 2. add logic code 3. test on dev box 4. run UT & regression test on dev box 5. code review after pass 1-4

...

-> check coding style compliance, with PHP_CodeSniffer and fix the reported issues. You can run Jenkins on your own box, or execute `phpcs filename` on the command line, more info on setting up Jenkins [1]

...

...

6. checkin code
7. check CI build

.....

I agree with you. so the process should be:

1. Add UT code
2. Add logic code
3. test on dev box
4. run UT & regression test on dev box
5. check coding style compliance, with PHP_CodeSniffer <---- I think we

should do it before code-review

I meant it to be part of the code reviewing. ;)

...

6. code review

-> 6.a run UT & regression test on dev box

best to test everything again after code reviewing and before commiting and checking in code.

...

7 checkin code 8 check CI build result

...

thanks,

Adam

-- Kind regards,

Dieter Adriaenssens

-- Kind regards,

Dieter Adriaenssens

Hey, Marc,

I would like to fix this bug. https://sourceforge.net/p/phpmyadmin/bugs/3742/

but I am quite confused about which space do you mean in the image? Attachment is the view from my side.

thanks Adam

Hi Marc,

After long time dissussion about the UNIT testing and regression testing. now I try to carry out to add some UNIT testing case firstly.

Following the pull request that I add UNIT test for PMA_Header_test: https://github.com/phpmyadmin/phpmyadmin/pull/233

-------------- adam

Hi Marc,

Le 2013-04-05 22:31, adam a écrit :

...

Hey, Marc,

I would like to fix this bug. https://sourceforge.net/p/phpmyadmin/bugs/3742/

but I am quite confused about which space do you mean in the image?

Attachment is the view from my side.

thanks

Adam

Hi Adam, I explain which space I mean, in the bug ticket. See my comment with the marc.png screenshot.

I found that on your screenshot (http://sourceforge.net/p/phpmyadmin/bugs/3742/), shows that 6 databases is displayed, but the navigator >>2 is displayed. I think you must change the configaration: $cfg['MaxNavigationItems'] = 25; to 6

otherwise, it is won't happen as your screenshot. If we want to fix this bug, we should make $cfg['MaxNavigationItems'] determined by space left.

so I want to check with you that. should we make $cfg['MaxNavigationItems'] a variable determined by space left.

Thanks, Adam