Help:Pickle/ja

'This is a page describing a proposed solution. It is not finalized, but an on-going work.'''

Sorry about that, to all those that want to do full spec-tests in Lua right away!''

''At some point this extension will probably be renamed, most likely to "pickles". You pick on something, and use gherkin-like languages, so pickles seems like a good name.''

Spec is a project to build an environment for continuous testing of Lua-scripts, which are used to implement advanced templates on a lot of sites and projects. Continuous testing is a core element of continuous delivery, which is very important for sites like Wikipedia that has to be up and running 24×7. Spec-style testing can be described as a variant of unit testing, or how to make the thing right.

Quick tour
How to set up and use spec tests, run them interactively and understand the reports. Some concepts are described on Help:Spec/Basic idea, but it is only a very coarse and simple description. There are some specific terms concerning specs in general and its use on wikis in particular. They have been defined in.

高度なツール
Some advanced tools are available, for specific purposes. They have been regrouped on these subjects:


 * The specs docpage can be given a special template that not only report the results on the doc page but also categorizes the page if the tests fails.
 * The specs docpage can be given a special template that not only report the results on the doc page but also categorizes the page if the tests fails.


 * Both test and source pages can run tests in the console. At the test page only a single test set will be run, but at the source page all subpages that is recognized as spec pages will be run.
 * Both test and source pages can run tests in the console. At the test page only a single test set will be run, but at the source page all subpages that is recognized as spec pages will be run.

作成中

 * A subpage is looked up and called as part of a parsed message. This lookup and parsing makes it possible to define a localized fallback chain, or even include and parse new test frameworks.
 * A subpage is looked up and called as part of a parsed message. This lookup and parsing makes it possible to define a localized fallback chain, or even include and parse new test frameworks.


 * The parsed text from the subpage will be processed by a simple extractor to see if it is possible to identify specific terms and phrases. If anyone are found then a specific token will be set before further processing.
 * The parsed text from the subpage will be processed by a simple extractor to see if it is possible to identify specific terms and phrases. If anyone are found then a specific token will be set before further processing.


 * The test report can be the final tokens used by the extension, but it can also be according to the Test Anything Protocol. It will then make an attempt to rewrite the tap-report into the final token.
 * The test report can be the final tokens used by the extension, but it can also be according to the Test Anything Protocol. It will then make an attempt to rewrite the tap-report into the final token.


 * All modules that has specs will have a page status indicator for the current result of the test, both as part of the symbol (by coloring) and the message (as text).
 * All modules that has specs will have a page status indicator for the current result of the test, both as part of the symbol (by coloring) and the message (as text).


 * All modules that has specs will have a tracking category for the current result of the test. It will follow the result as shown by the page status indicator.
 * All modules that has specs will have a tracking category for the current result of the test. It will follow the result as shown by the page status indicator.


 * All modules that has specs will add entries to the test status log for the current result of the test. It will follow the result as shown by the page status indicator.
 * All modules that has specs will add entries to the test status log for the current result of the test. It will follow the result as shown by the page status indicator.


 * It is possible to calculate software metrics for modules, and especially cyclomatic complexity is a very interesting metric as it gives upper and lower bounds for the number of necessary tests.
 * It is possible to calculate software metrics for modules, and especially cyclomatic complexity is a very interesting metric as it gives upper and lower bounds for the number of necessary tests.