<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<STYLE>
BLOCKQUOTE {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
BODY {
LINE-HEIGHT: 1.5; FONT-FAMILY: Segoe UI; COLOR: #000080; FONT-SIZE: 10.5pt
}
</STYLE>
<META name=GENERATOR content="MSHTML 8.00.7601.18094"></HEAD>
<BODY style="MARGIN: 10px">
<DIV>Hi,</DIV>
<DIV> </DIV>
<DIV>
<DIV>>Just consider that some things are not outputted to the browser, like
exporting and importing.</DIV></DIV>
<DIV style="COLOR: #333399; FONT-SIZE: 10.5pt"> </DIV>
<DIV style="COLOR: #333399; FONT-SIZE: 10.5pt">In my mind, selenium lite version
can't acchive this target, but we can use <SPAN
style="TEXT-ALIGN: left; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; DISPLAY: inline !important; FONT: 10.5pt/18px Arial, 'Liberation Sans', 'DejaVu Sans', sans-serif; WHITE-SPACE: normal; FLOAT: none; LETTER-SPACING: normal; COLOR: #333399; WORD-SPACING: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px">WebDriver<SPAN
style="COLOR: #333399; FONT-SIZE: 10.5pt" class=Apple-converted-space> to
cover this situation. It is not the most important case in our testing, use page
checking ,we can cover 90% important functional case.</SPAN></SPAN></DIV>
<DIV> </DIV>
<DIV>I will try to cover some important functional case besides Unit testing
when doing the GSOC project: Automatic testing </DIV>
<DIV> </DIV>
<DIV>Thanks</DIV>
<DIV> </DIV>
<DIV> </DIV>
<HR style="WIDTH: 210px; HEIGHT: 1px" align=left color=#b5c4df SIZE=1>
<DIV><SPAN>adam</SPAN></DIV>
<DIV> </DIV>
<DIV
style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0cm; PADDING-LEFT: 0cm; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<DIV
style="PADDING-BOTTOM: 8px; PADDING-LEFT: 8px; PADDING-RIGHT: 8px; BACKGROUND: #efefef; COLOR: #000000; FONT-SIZE: 12px; PADDING-TOP: 8px">
<DIV><B>From:</B> <A href="mailto:dieter.adriaenssens@gmail.com">Dieter
Adriaenssens</A></DIV>
<DIV><B>Date:</B> 2013-03-31 23:55</DIV>
<DIV><B>To:</B> <A href="mailto:adamgsoc2013@gmail.com">adam adam</A></DIV>
<DIV><B>CC:</B> <A
href="mailto:phpmyadmin-devel@lists.sourceforge.net">phpmyadmin-devel</A></DIV>
<DIV><B>Subject:</B> Re: Re: [Phpmyadmin-devel] Automatic
testing</DIV></DIV></DIV>
<DIV>
<DIV>2013/3/31 adam adam <adamgsoc2013@gmail.com></DIV>
<DIV>></DIV>
<DIV>> Hi,</DIV>
<DIV>></DIV>
<DIV>> 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.)</DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV>> > How do you plan to automate the functional tests?</DIV>
<DIV>> 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></DIV>
<DIV> </DIV>
<DIV>Sure.</DIV>
<DIV>Just consider that some things are not outputted to the browser, like</DIV>
<DIV>exporting and importing.</DIV>
<DIV> </DIV>
<DIV>></DIV>
<DIV>> in other word, we can use selenium to check Page element is loaded correctly, I think this work is as important as Unit test.</DIV>
<DIV>></DIV>
<DIV>> other benefit, we can cover phpmyadmin can work well one GradeA browsers.</DIV>
<DIV>> 1. check the page is loaded correctly</DIV>
<DIV>> 2. check the page is working well on GradeA browsers.</DIV>
<DIV>> 3. check the css/js is working well</DIV>
<DIV>> ......</DIV>
<DIV>></DIV>
<DIV>> > 5. check coding style compliance, with PHP_CodeSniffer <---- I think we</DIV>
<DIV>> > should do it before code-review</DIV>
<DIV>></DIV>
<DIV>> > I meant it to be part of the code reviewing. ;)</DIV>
<DIV>></DIV>
<DIV>> > 6. code review</DIV>
<DIV>></DIV>
<DIV>> > -> 6.a run UT & regression test on dev box</DIV>
<DIV>></DIV>
<DIV>> >best to test everything again after code reviewing and before commiting and checking in code.</DIV>
<DIV>></DIV>
<DIV>> > 7 checkin code</DIV>
<DIV>> > 8 check CI build result</DIV>
<DIV>></DIV>
<DIV>> totally agree, codesniffer can be one part of CI job, if the codesniffer failed, the CI should failed as well.</DIV>
<DIV> </DIV>
<DIV>Codesniffer is already a part of CI (see Jenkins reports [0]). I meant</DIV>
<DIV>that you should check your coding style of the changes you made,</DIV>
<DIV>before commiting.</DIV>
<DIV> </DIV>
<DIV>[0] http://ci.phpmyadmin.net/job/phpMyAdmin/</DIV>
<DIV> </DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV>> thanks,</DIV>
<DIV>></DIV>
<DIV>> Adam</DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV>> On Fri, Mar 29, 2013 at 6:41 PM, Dieter Adriaenssens <dieter.adriaenssens@gmail.com> wrote:</DIV>
<DIV>>></DIV>
<DIV>>> 2013/3/29 adam <adamgsoc2013@gmail.com>:</DIV>
<DIV>>> > Hi Dieter,</DIV>
<DIV>>> ></DIV>
<DIV>>> > thanks for your reply. I was trying to apply the GSOC topic: Automatic</DIV>
<DIV>>> > testing. so I want to check with you guys about the fomal process</DIV>
<DIV>>> ></DIV>
<DIV>>> >> What do you mean by regression tests? How are they different from unit</DIV>
<DIV>>> >> tests?</DIV>
<DIV>>> >> The process you describe sounds reasonable. If you rearrange the order</DIV>
<DIV>>> >> a bit, and add codechecking to your process, you are on your way of</DIV>
<DIV>>> >> writing good code (see below for suggestions)</DIV>
<DIV>>> ></DIV>
<DIV>>> > In my mind, the regression tests is different from the unit tests. or in</DIV>
<DIV>>> > other word, we can say that the regression test include Unit tests.</DIV>
<DIV>>> > the regression test can include function test case beside unit tests.</DIV>
<DIV>>> ></DIV>
<DIV>>> > In my mind, in order to gurantee the code quality, UNIT test just cover the</DIV>
<DIV>>> > code logic, but Fuinctional test can be end to end case with real case.</DIV>
<DIV>>></DIV>
<DIV>>> Ok, makes sense. How do you plan to automate the functional tests?</DIV>
<DIV>>></DIV>
<DIV>>> >> In my mind, the fomal processes should be:</DIV>
<DIV>>> >> 1. add UT code</DIV>
<DIV>>> >> (TDD [0] principle, write tests first, then start implementing the</DIV>
<DIV>>> >> class/method)</DIV>
<DIV>>> >> 2. add logic code</DIV>
<DIV>>> >> 3. test on dev box</DIV>
<DIV>>> >> 4. run UT & regression test on dev box</DIV>
<DIV>>> >> 5. code review after pass 1-4</DIV>
<DIV>>> ></DIV>
<DIV>>> >> -> check coding style compliance, with PHP_CodeSniffer and fix the</DIV>
<DIV>>> >> reported issues.</DIV>
<DIV>>> >> You can run Jenkins on your own box, or execute `phpcs filename` on</DIV>
<DIV>>> >> the command line, more info on setting up Jenkins [1]</DIV>
<DIV>>> ></DIV>
<DIV>>> >> > 6. checkin code</DIV>
<DIV>>> >>> 7. check CI build</DIV>
<DIV>>> >>> .....</DIV>
<DIV>>> ></DIV>
<DIV>>> ></DIV>
<DIV>>> > I agree with you. so the process should be:</DIV>
<DIV>>> > 1. Add UT code</DIV>
<DIV>>> > 2. Add logic code</DIV>
<DIV>>> > 3. test on dev box</DIV>
<DIV>>> > 4. run UT & regression test on dev box</DIV>
<DIV>>> > 5. check coding style compliance, with PHP_CodeSniffer <---- I think we</DIV>
<DIV>>> > should do it before code-review</DIV>
<DIV>>></DIV>
<DIV>>> I meant it to be part of the code reviewing. ;)</DIV>
<DIV>>></DIV>
<DIV>>> > 6. code review</DIV>
<DIV>>></DIV>
<DIV>>> -> 6.a run UT & regression test on dev box</DIV>
<DIV>>></DIV>
<DIV>>> best to test everything again after code reviewing and before</DIV>
<DIV>>> commiting and checking in code.</DIV>
<DIV>>></DIV>
<DIV>>> > 7 checkin code</DIV>
<DIV>>> > 8 check CI build result</DIV>
<DIV>>></DIV>
<DIV>>></DIV>
<DIV>>></DIV>
<DIV>>> > thanks,</DIV>
<DIV>>> ></DIV>
<DIV>>> > Adam</DIV>
<DIV>>></DIV>
<DIV>>></DIV>
<DIV>>></DIV>
<DIV>>> --</DIV>
<DIV>>> Kind regards,</DIV>
<DIV>>></DIV>
<DIV>>> Dieter Adriaenssens</DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>--</DIV>
<DIV>Kind regards,</DIV>
<DIV> </DIV>
<DIV>Dieter Adriaenssens</DIV></DIV></BODY></HTML>