tests/README.md - Issue 29501558: Issue 5383 - Add tests for the Chrome and Firefox packagers

Side by Side Diff: tests/README.md

Issue 29501558: Issue 5383 - Add tests for the Chrome and Firefox packagers (Closed)

Patch Set: Asserting PNGs Created Sept. 19, 2017, 10:02 a.m.

Left:
Right:

Use n/p to move between diff chunks; N/P to move between comments.

Jump to:

View unified diff | Download patch

OLD	NEW
(Empty)
	1 # Buildtools unit tests

	2

	3 ## Introduction

	4

	5 Unit tests for buildtools, using the pytest framework.

	6

	7 ## Approach

	8

	9 In order to test the buildtools capability of creating WebExtension-packages

	10 for Chrome, Edge and Firefox, an example configuration for each platform is

	11 provided.

	12 Running the tests calls the same API as the cli would, except for releases

	13 (we don't want to trigger our releaseAutomation during tests) - in this case,

	14 a build is manually created and verified)

	15

	16 Each extension is build with different parameters, the resulting package and

	17 it's content is compared against provided expected results:

	18

	19 - Release or build-only, with or without a specific build-number (Edge)

	20 - Release, build-only or developement environment, with or without a specifc

	21 build-number (Chrome, Firefox), with or without a predefined signing key

	22 (Chrome)

	23

	24 The expected results for each manifest are provided with the files in

	25 `expecteddata/`.

	26

	27 ## Test cases

	28

	29 _(covered platforms are referred to as C=Chrome, E=Edge, F=Firefox)_

	30

	31 - Metadata inheritance (EF)

	32 - correct package filename (CEF)

	33 - Printed warning about non-square icons (CF)

	34 - Presence of javascript unit test files in developement environment (CF)

	35 - Absence of javascript unit test files in build-only or release (CF)

	36 - Inlcusion of defined contentScripts into the manifest (CF)

	37 - Packaging (and moving) of included icons / scripts / htmls (CEF)

	38 - Presence of files for all configured locales (CEF)

	39 - Correct import of translations with or without placeholders, with or without

	40 access keys (CF)

	41 - Translation presence and validity for the Chrome Web Store (C)

	42 - Packaging of modularized script files (CF)

	43 - Adherence to provided build-number in the manifest (CEF)

	44 - Other content in the manifest (CEF)

	45 - Correct encrypted signature of the package (C)

	46

	47 ## Requirements

	48

	49 - [Tox](https://pypi.python.org/pypi/tox) (>= 2.7.0)

	50

	51 _(Tox will take care of installing the other dependencies such as flake8 and

	52 flake8-abp inside a virtualenv.)_

	53

	54 ## Usage

	55

	56 To run the tests simply run

	57

	58 `tox`
	Vasily Kuznetsov 2017/09/19 17:52:26 You can use a 4 space indent here instead, and I w You can use a 4 space indent here instead, and I would also suggest adding a shell prompt before "tox" so it's clear that we run it from shell prompt. Something like this: $ tox Sebastian Noack 2017/09/20 00:58:01 Actually, since the whole paragraph consists of co Show quoted text On 2017/09/19 17:52:26, Vasily Kuznetsov wrote: > You can use a 4 space indent here instead, and I would also suggest adding a > shell prompt before "tox" so it's clear that we run it from shell prompt. > Something like this: > > $ tox Actually, since the whole paragraph consists of code, you should rather use triple backticks and no indentation at all: ``` $ tox ``` tlucas 2017/09/20 08:52:50 Done. Show quoted text On 2017/09/20 00:58:01, Sebastian Noack wrote: > On 2017/09/19 17:52:26, Vasily Kuznetsov wrote: > > You can use a 4 space indent here instead, and I would also suggest adding a > > shell prompt before "tox" so it's clear that we run it from shell prompt. > > Something like this: > > > > $ tox > > Actually, since the whole paragraph consists of code, you should rather use > triple backticks and no indentation at all: > > ``` > $ tox > ``` Done. Vasily Kuznetsov 2017/09/20 14:53:04 Seems like it's more cluttered and harder to read Show quoted text On 2017/09/20 00:58:01, Sebastian Noack wrote: > On 2017/09/19 17:52:26, Vasily Kuznetsov wrote: > > You can use a 4 space indent here instead, and I would also suggest adding a > > shell prompt before "tox" so it's clear that we run it from shell prompt. > > Something like this: > > > > $ tox > > Actually, since the whole paragraph consists of code, you should rather use > triple backticks and no indentation at all: > > ``` > $ tox > ``` Seems like it's more cluttered and harder to read source code that produces the same output. Why do you think this is better than just a simple code block? Sebastian Noack 2017/09/20 21:36:09 The output is usually not the same (it might depen Show quoted text On 2017/09/20 14:53:04, Vasily Kuznetsov wrote: > On 2017/09/20 00:58:01, Sebastian Noack wrote: > > On 2017/09/19 17:52:26, Vasily Kuznetsov wrote: > > > You can use a 4 space indent here instead, and I would also suggest adding a > > > shell prompt before "tox" so it's clear that we run it from shell prompt. > > > Something like this: > > > > > > $ tox > > > > Actually, since the whole paragraph consists of code, you should rather use > > triple backticks and no indentation at all: > > > > ``` > > $ tox > > ``` > > Seems like it's more cluttered and harder to read source code that produces the > same output. Why do you think this is better than just a simple code block? The output is usually not the same (it might depend on the markdown renderer though). Single backticks usually (e.g. on GitHub) don't render as code block, but render a code snippet, and are meant for code inside a text paragraph. Vasily Kuznetsov 2017/09/21 09:29:02 I agree about the single backticks, but my proposa Show quoted text On 2017/09/20 21:36:09, Sebastian Noack wrote: > On 2017/09/20 14:53:04, Vasily Kuznetsov wrote: > > On 2017/09/20 00:58:01, Sebastian Noack wrote: > > > On 2017/09/19 17:52:26, Vasily Kuznetsov wrote: > > > > You can use a 4 space indent here instead, and I would also suggest adding > a > > > > shell prompt before "tox" so it's clear that we run it from shell prompt. > > > > Something like this: > > > > > > > > $ tox > > > > > > Actually, since the whole paragraph consists of code, you should rather use > > > triple backticks and no indentation at all: > > > > > > ``` > > > $ tox > > > ``` > > > > Seems like it's more cluttered and harder to read source code that produces > the > > same output. Why do you think this is better than just a simple code block? > > The output is usually not the same (it might depend on the markdown renderer > though). Single backticks usually (e.g. on GitHub) don't render as code block, > but render a code snippet, and are meant for code inside a text paragraph. I agree about the single backticks, but my proposal was a code block (https://daringfireball.net/projects/markdown/syntax#precode). Sebastian Noack 2017/09/21 19:09:02 Oh, I didn't know of that syntax, I was assuming y Show quoted text On 2017/09/21 09:29:02, Vasily Kuznetsov wrote: > On 2017/09/20 21:36:09, Sebastian Noack wrote: > > On 2017/09/20 14:53:04, Vasily Kuznetsov wrote: > > > On 2017/09/20 00:58:01, Sebastian Noack wrote: > > > > On 2017/09/19 17:52:26, Vasily Kuznetsov wrote: > > > > > You can use a 4 space indent here instead, and I would also suggest > adding > > a > > > > > shell prompt before "tox" so it's clear that we run it from shell > prompt. > > > > > Something like this: > > > > > > > > > > $ tox > > > > > > > > Actually, since the whole paragraph consists of code, you should rather > use > > > > triple backticks and no indentation at all: > > > > > > > > ``` > > > > $ tox > > > > ``` > > > > > > Seems like it's more cluttered and harder to read source code that produces > > the > > > same output. Why do you think this is better than just a simple code block? > > > > The output is usually not the same (it might depend on the markdown renderer > > though). Single backticks usually (e.g. on GitHub) don't render as code block, > > but render a code snippet, and are meant for code inside a text paragraph. > > I agree about the single backticks, but my proposal was a code block > (https://daringfireball.net/projects/markdown/syntax#precode). Oh, I didn't know of that syntax, I was assuming you were suggesting to keep the single backticks but just change the indentation. But indeed indented code is rendered the same as code wrapped in triple backticks, but reads nicer in plain text. The only downside seems to be that you cannot annotate the programming language for code hightlighting, but that doesn't matter here. Tristan, so if you want to go with Vasily's suggestion, fine with me.
	59

	60 in the buildtools' rootfolder.
	Sebastian Noack 2017/09/20 00:58:01 In English, you can not make up new words by putti In English, you can not make up new words by putting two words together. So it is "root folder", not "rootfolder". tlucas 2017/09/20 08:52:51 Done. Show quoted text On 2017/09/20 00:58:01, Sebastian Noack wrote: > In English, you can not make up new words by putting two words together. So it > is "root folder", not "rootfolder". Done.
	61

	62 ## Coverage

	63

	64 Pytest will create a coverage report as output to the terminal, using the

	65 pytest plugin `pytest-cov`.

	66

	67 In order to get an html report you can add `--cov-report=html` to the

	68 pytest-command in tox.ini.

	69

	70 For more information please refer to the

	71 [coverage documentation](https://coverage.readthedocs.io/)

OLD	NEW

« packagerChrome.py ('K') | « packagerChrome.py ('k') | tests/__init__.py » ('j') | tests/test_packagerWebExt.py » ('J')