[Phpmyadmin-devel] Automatic testing

Dieter Adriaenssens dieter.adriaenssens at gmail.com
Sun Mar 31 17:55:01 CEST 2013


2013/3/31 adam adam <adamgsoc2013 at 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 at gmail.com> wrote:
>>
>> 2013/3/29 adam <adamgsoc2013 at 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




More information about the Developers mailing list