u/pc/rhodecode-enterprise-ce-fork-pc Files · docs/contributing/testing/spec-by-example.rst

integrations: refactor/cleanup + features, fixes ...

integrations: refactor/cleanup + features, fixes * added scopes on integrations, scopes are: - repo only - repogroup children only - root repos only - global (any repo) * integrations schemas now have separate section for the settings (eg. slack) and options (eg. scope/enabled) * added descriptions to integration types * added icons to integration types * added 'create new' integration page * added scope of integration to integrations list * added breadcrumbs for each repo/repogroup/global integrations pages * added sorting to integrations list * added pagination to integrations list * added icons to integrations list * added type filter to integrations list * added message to integrations list if none we found * added extra permissions check on integrations views * db migration from 56 => 57 - adds child_repos_only field * added tests for integrations triggered on events * added tests for integrations schemas * added tests for integrations views for repo/repogroup/admin

lisaq - - Load All Authors

File last commit:

r271:401985cc default


                r731:7a6d3636

default

Download file

             spec-by-example.rst
        
                    75 lines
            
             | 1.9 KiB
            
                | text/x-rst
            
             |
                RstLexer
            
             / docs / contributing / testing / spec-by-example.rst
          
                    History
                
                 |
                  Source
                 | Raw
                 |Copy content
                 |Copy permalink

        marcink
    
project: added all source files and assets

              r1
            
      .. _test-spec-by-example:

      ==========================

       Specification by Example

      ==========================

      .. Avoid duplicating the quickstart instructions by importing the README

         file.

      .. include:: ../../../acceptance_tests/README.rst

      Choices of technology and tools

      ===============================

      `nix` as runtime environment

      ----------------------------

      We settled to use the `nix` tools to provide us the needed environment for

      running the tests.

      `Gherkins` as specification language

      ------------------------------------

      To specify by example, we settled on Gherkins as the semi-formal specification

      language.

      `py.test` as a runner

      ---------------------

      After experimenting with `behave` and `py.test` our choice was `pytest-bdd`

      because it allows us to use our existing knowledge about `py.test` and avoids

      that we have to learn another tool.

      Concepts

      ========

      The logic is structured around the design pattern of "page objects". The

      documentation of `python-selemium` contains a few more details about this

      pattern.

      Page Objects

      ------------

      We introduce an abstraction class for every page which we have to interact with

      in order to validate the specifications.

      The implementation for the page objects is inside of the module

      :mod:`page_objects`. The class :class:`page_objects.base.BasePage` should be

      used as a base for all page object implementations.

      Locators

      --------

      The specific information how to locate an element inside of the DOM tree of a

        lisaq
    
docs: updates to contributor documentation #4039

              r271
            
      page is kept in a separate class. This class serves mainly as a data container;

        marcink
    
project: added all source files and assets

              r1
            
      it shall not contain any logic.

      The reason for keeping the locators separate is that we expect a frequent need

        lisaq
    
docs: updates to contributor documentation #4039

              r271
            
      for change whenever we work on our templates. In such a case, it is more

      efficient to have all of thelocators together and update them there instead of

      having to find every locator inside of the logic of a page object.

	Site-wide shortcuts
/	Use quick search box
g h	Goto home page
g g	Goto my private gists page
g G	Goto my public gists page
g 0-9	Goto bookmarked items from 0-9
n r	New repository page
n g	New gist page

	Repositories
g s	Goto summary page
g c	Goto changelog page
g f	Goto files page
g F	Goto files page with file search activated
g p	Goto pull requests page
g o	Goto repository settings
g O	Goto repository access permissions settings
t s	Toggle sidebar on some pages

marcink project: added all source files and assets	r1
		.. _test-spec-by-example:

		==========================
		Specification by Example
		==========================


		.. Avoid duplicating the quickstart instructions by importing the README
		file.

		.. include:: ../../../acceptance_tests/README.rst



		Choices of technology and tools
		===============================


		`nix` as runtime environment
		----------------------------

		We settled to use the `nix` tools to provide us the needed environment for
		running the tests.



		`Gherkins` as specification language
		------------------------------------

		To specify by example, we settled on Gherkins as the semi-formal specification
		language.


		`py.test` as a runner
		---------------------

		After experimenting with `behave` and `py.test` our choice was `pytest-bdd`
		because it allows us to use our existing knowledge about `py.test` and avoids
		that we have to learn another tool.



		Concepts
		========

		The logic is structured around the design pattern of "page objects". The
		documentation of `python-selemium` contains a few more details about this
		pattern.



		Page Objects
		------------

		We introduce an abstraction class for every page which we have to interact with
		in order to validate the specifications.

		The implementation for the page objects is inside of the module
		:mod:`page_objects`. The class :class:`page_objects.base.BasePage` should be
		used as a base for all page object implementations.



		Locators
		--------

		The specific information how to locate an element inside of the DOM tree of a
lisaq docs: updates to contributor documentation #4039	r271	page is kept in a separate class. This class serves mainly as a data container;
marcink project: added all source files and assets	r1	it shall not contain any logic.

		The reason for keeping the locators separate is that we expect a frequent need
lisaq docs: updates to contributor documentation #4039	r271	for change whenever we work on our templates. In such a case, it is more
		efficient to have all of thelocators together and update them there instead of
		having to find every locator inside of the logic of a page object.