Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "PDT/Testing Framework - PDTT"
Roy.zend.com (Talk | contribs) |
|||
| (23 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == pdtt - Test | + | <pre> pdtt is a clone of the popular phpt </pre> |
| + | |||
| + | == pdtt - Test Eclipse PDT Code Assist == | ||
| + | The first thing you need to know about tests is that we need more!!! Although Eclipse PDT code assist works just great 99.99% of the time, not having a very comprehensive test suite means that we take more risks every time we add to or modify the Eclipse PDT Code Assist Engine implementation. The second thing you need to know is that if you can write PHP you can write tests. Thirdly - we are a friendly and welcoming community, don't be scared about writing to ([https://dev.eclipse.org/mailman/listinfo/pdt-dev pdt-dev@eclipse.org]) - we won't bite! | ||
| + | |||
| + | ==== So what are pdtt tests? ==== | ||
| + | A pdtt test is a little script used by the pdt internal and quality assurance teams to test Eclipse PDT's code assist functionality. It can be used with new releases to make sure they can do all the things that previous releases can, or to help find bugs in current releases. By writing pdtt tests you are helping to make Eclipse PDT more stable. | ||
| + | ====What skills are needed to write a pdtt test?==== | ||
| + | All that is really needed to write a pdtt test is a basic understanding of the PHP language, a text editor, and a way to get the results of your code. That is it. So if you have been writing and running PHP scripts already - you have everything you need. | ||
| + | ====What do you write pdtt tests on?==== | ||
| + | Basically you can write a pdtt test on one of the various code assist scenarios available. You can write a test on a basic language element (a type, function or variable). | ||
| + | If you want more guidance than that you can always ask the Eclipse PDT Quality Assurance Team on their mailing list (pdt-dev@eclipse.org) where they would like you to direct your attentions. | ||
| + | ====How is a pdtt test is used?==== | ||
| + | When a test is called by the TestPdttScripts it takes various parts of the pdtt file to name and create a .php file. That .php file is then saved in a temporary project. The location that is marked with "|" is used to initiate the code assist engine. If the proposals of the engine "match" the proposals provided in the pdtt script - it passes. | ||
| + | ====What should a pdtt test do?==== | ||
| + | Basically - it should try and break the Eclipse PDT Code Assist Engine. It should check not only the regular code assist proposals, but it should also check edge cases. | ||
| + | |||
| + | ==Writing pdtt Tests== | ||
| + | ====Naming Conventions==== | ||
| + | Pdtt tests follow a very strict naming convention. This is done to easily identify what each pdtt test is for. Tests should be named according to the following list: | ||
| + | * Tests for bugs - testBug<bugid>.pdtt (testBug17123.pdtt) | ||
| + | * General tests for specific scenario - test<name><no>.phpt (testNamespace_003.pdtt) | ||
| + | |||
| + | ====How big is a test case?==== | ||
| + | Small. Really - the smaller the better, a good guide is no more than 10 lines of output. The reason for this is that if we break something in Eclipse PDT Code Assist Engine and it breaks your test case we need to be able to find out quite quickly what we broke, going through 1000s of line of test case output is not easy. Having said that it's sometimes just not practical to stay within the 10 line guideline, in this case you can help a lot by commenting the output. | ||
| + | |||
| + | ==Basic Format== | ||
| + | A test must contain the sections TEST, FILE and either EXPECT at a minimum. The example below illustrates a minimal test. | ||
<pre> | <pre> | ||
| − | + | --TEST-- | |
| + | Tests a simple class name completion in namespace | ||
| + | --FILE-- | ||
| + | <? namespace My; class A {} class b { } $a = new My\| ?> | ||
| + | --EXPECT-- | ||
| + | type(A) | ||
| + | type(B) | ||
</pre> | </pre> | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | As you can see the file is divided into several sections. The TEST section holds a one line title of the phpt test, this shoudl be a simple description and shouldn't ever excede one line, if you need to write more explanation add comments in the body of the test case. The phpt files name is used when generating a .php file. The FILE section is used as the body of the .php file, so don't forget to open and close your php tags. The EXPECT section is the part used as a comparison to see if the test passes. Expected output is a list of: type(A), method(A), field(A) or keyword(A) entries, where A is an element name and 'type', 'method', 'field' or 'keyword' are element types: | ||
| − | + | a) 'type' refers to class, interface or namespace | |
| − | + | b) 'method' refers to method or function | |
| − | + | c) 'field' refers to variable or constant | |
| + | d) 'keyword' refers to a PHP keyword or PHPDoc tag. | ||
| + | You can review the [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.pdt/tests/org.eclipse.php.test/workspace/codeassist/?root=Tools_Project existing examples here] | ||
| − | == | + | == What should I do with my test case when I've written and tested it?== |
| + | The next step is to get someone to review it. If it's short you can paste it into a note and send it to [https://dev.eclipse.org/mailman/listinfo/pdt-dev pdt-dev@eclipse.org]. If the test is a bit too long for that then put it somewhere were people can download it ([http://www.pastebin.ca pastebin] is sometimes used). Appending tests to notes as files doesn't work well - so please don't do that. Your note to pdt-dev@eclipse.org should say what level of Eclipse PDT you have tested it on and what platform(s) you've run it on. Someone from the Eclipse PDT group will review your test and reply to you. They may ask for some changes or suggest better ways to do things, or they may commit it to Eclipse PDT. | ||
| − | + | [[Category:PDT]] | |
| − | + | ||
Latest revision as of 16:13, 21 October 2015
pdtt is a clone of the popular phpt
Contents
pdtt - Test Eclipse PDT Code Assist
The first thing you need to know about tests is that we need more!!! Although Eclipse PDT code assist works just great 99.99% of the time, not having a very comprehensive test suite means that we take more risks every time we add to or modify the Eclipse PDT Code Assist Engine implementation. The second thing you need to know is that if you can write PHP you can write tests. Thirdly - we are a friendly and welcoming community, don't be scared about writing to (pdt-dev@eclipse.org) - we won't bite!
So what are pdtt tests?
A pdtt test is a little script used by the pdt internal and quality assurance teams to test Eclipse PDT's code assist functionality. It can be used with new releases to make sure they can do all the things that previous releases can, or to help find bugs in current releases. By writing pdtt tests you are helping to make Eclipse PDT more stable.
What skills are needed to write a pdtt test?
All that is really needed to write a pdtt test is a basic understanding of the PHP language, a text editor, and a way to get the results of your code. That is it. So if you have been writing and running PHP scripts already - you have everything you need.
What do you write pdtt tests on?
Basically you can write a pdtt test on one of the various code assist scenarios available. You can write a test on a basic language element (a type, function or variable). If you want more guidance than that you can always ask the Eclipse PDT Quality Assurance Team on their mailing list (pdt-dev@eclipse.org) where they would like you to direct your attentions.
How is a pdtt test is used?
When a test is called by the TestPdttScripts it takes various parts of the pdtt file to name and create a .php file. That .php file is then saved in a temporary project. The location that is marked with "|" is used to initiate the code assist engine. If the proposals of the engine "match" the proposals provided in the pdtt script - it passes.
What should a pdtt test do?
Basically - it should try and break the Eclipse PDT Code Assist Engine. It should check not only the regular code assist proposals, but it should also check edge cases.
Writing pdtt Tests
Naming Conventions
Pdtt tests follow a very strict naming convention. This is done to easily identify what each pdtt test is for. Tests should be named according to the following list:
- Tests for bugs - testBug<bugid>.pdtt (testBug17123.pdtt)
- General tests for specific scenario - test<name><no>.phpt (testNamespace_003.pdtt)
How big is a test case?
Small. Really - the smaller the better, a good guide is no more than 10 lines of output. The reason for this is that if we break something in Eclipse PDT Code Assist Engine and it breaks your test case we need to be able to find out quite quickly what we broke, going through 1000s of line of test case output is not easy. Having said that it's sometimes just not practical to stay within the 10 line guideline, in this case you can help a lot by commenting the output.
Basic Format
A test must contain the sections TEST, FILE and either EXPECT at a minimum. The example below illustrates a minimal test.
--TEST--
Tests a simple class name completion in namespace
--FILE--
<? namespace My; class A {} class b { } $a = new My\| ?>
--EXPECT--
type(A)
type(B)
As you can see the file is divided into several sections. The TEST section holds a one line title of the phpt test, this shoudl be a simple description and shouldn't ever excede one line, if you need to write more explanation add comments in the body of the test case. The phpt files name is used when generating a .php file. The FILE section is used as the body of the .php file, so don't forget to open and close your php tags. The EXPECT section is the part used as a comparison to see if the test passes. Expected output is a list of: type(A), method(A), field(A) or keyword(A) entries, where A is an element name and 'type', 'method', 'field' or 'keyword' are element types:
a) 'type' refers to class, interface or namespace b) 'method' refers to method or function c) 'field' refers to variable or constant d) 'keyword' refers to a PHP keyword or PHPDoc tag.
You can review the existing examples here
What should I do with my test case when I've written and tested it?
The next step is to get someone to review it. If it's short you can paste it into a note and send it to pdt-dev@eclipse.org. If the test is a bit too long for that then put it somewhere were people can download it (pastebin is sometimes used). Appending tests to notes as files doesn't work well - so please don't do that. Your note to pdt-dev@eclipse.org should say what level of Eclipse PDT you have tested it on and what platform(s) you've run it on. Someone from the Eclipse PDT group will review your test and reply to you. They may ask for some changes or suggest better ways to do things, or they may commit it to Eclipse PDT.