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(a)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(a)gmail.com> wrote:
2013/3/29 adam <adamgsoc2013(a)gmail.com>om>:
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