diff --git a/frontend/elements/dragndrop/dragndrop.md b/frontend/elements/dragndrop/dragndrop.md index a261c8f..376367e 100644 --- a/frontend/elements/dragndrop/dragndrop.md +++ b/frontend/elements/dragndrop/dragndrop.md @@ -7,7 +7,7 @@ Elements can be made drag and droppable which can be helpful to allow users to r In order to make elements drag and droppable you must define a container which contains all the drag and droppable elements. ```html -
+
``` @@ -16,7 +16,7 @@ In order to make elements drag and droppable you must define a container which c Elements which should be draggable in the container must be marked with `draggable="true"`. ```html -
+
1
2
3
diff --git a/frontend/forms/forms.md b/frontend/forms/forms.md index 6feaa43..88e4be9 100644 --- a/frontend/forms/forms.md +++ b/frontend/forms/forms.md @@ -1,9 +1,17 @@ # Forms +Handling data is very important for the application which makes forms and data display very important. + +Basically any element that can contain child elements can be a form, this includes `
` elements but also elements which are marked as form with a data binding `data-tag="form"`. This gives a lot of options as now divs or tables can be used as forms. + +**Important:** Every form MUST have an ID defined, if this attribute is not set an element will not get recognized as form, even if it is the `` element itself! + ## Bindings data-tag : tells the element how to behave (e.g. turn none-form elements into forms by defining it as "form") + data-method : method definition for none-form elements (not used for actual forms, where method can be used) +data-method-delete : delete request endpoint if a special endpoint is required data-marker=tpl : ??? maybe entries which are templates (e.g. inline add or inline edit?) **check** data-id : Data id (primary id value, by which it is stored in the database) @@ -38,23 +46,24 @@ data-tpl-value-path : remote path for the text - [x] DragDrop - [ ] Remote DragDrop - [x] Remove -- [ ] Remote Remove +- [ ] Remote Remove (easy, only submit data) - [ ] Remote Update on change (no save button required) -### Heartbeat -- [ ] Remote adds (heartbeat checks) -- [ ] Remote updates (heartbeat checks) -- [ ] Remote removes (heartbeat checks) - ### External - [x] add -- [ ] update -- [ ] remote add -- [ ] remote update +- [x] update - [x] cancel +- [ ] remote add (easy, only submit data) +- [ ] remote update (easy, only submit data) ### Internal - [ ] add - [ ] update -- [ ] remote add -- [ ] remote update \ No newline at end of file +- [ ] cancel +- [ ] remote add (easy, only submit data) +- [ ] remote update (easy only submit data) + +### Heartbeat (not form specific) +- [x] Remote adds (heartbeat checks) +- [x] Remote updates (heartbeat checks) +- [x] Remote removes (heartbeat checks) diff --git a/general/first_steps.md b/general/first_steps.md index 5ebe13d..5b69819 100644 --- a/general/first_steps.md +++ b/general/first_steps.md @@ -5,6 +5,7 @@ After you installed the application and configured your development environment Please note that besides the general development guide the organization also provides various other organizational documents which help to understand the processes, development status and decisions made. * [Development process](https://github.com/Karaka-Management/Docs/blob/master/Processes/Development.md) +* [Code inspection]({%}?page=quality/inspections) * [Project status](https://github.com/Karaka-Management/Docs/blob/master/Project/PROJECT.md) * [Code of conduct](https://github.com/Karaka-Management/Docs/blob/master/Policies%20%26%20Guidelines/Code%20of%20conduct.md) * [Conflict of interest](https://github.com/Karaka-Management/Docs/blob/master/Policies%20%26%20Guidelines/Conflict%20of%20Interest%20Policy.md) diff --git a/general/setup.md b/general/setup.md index 62cd708..afbef6e 100755 --- a/general/setup.md +++ b/general/setup.md @@ -22,8 +22,10 @@ Which IDE or editor a developer uses is up to the individual developer. From exp ## Application install options -1. Option: Only installs the application, due to the large amount of data takes some time to execute. **Recommended** -2. Option: Only installs the application with some tests. Requires you to install the dev tools in advance. **Recommended** +Option 1 and 2 require you to install the dev tools in advance! + +1. Option: Installs the application (with a lot of dummy data, this may take a long time). **Recommended** +2. Option: Installs the application (with or without performing tests). **Recommended** 3. Option: Full installation, code checks/tests, generating documentation. **Not recomended** ### Option 1: Demo Application diff --git a/quality/inspections.md b/quality/inspections.md index 1eb4dcd..df2dc4e 100755 --- a/quality/inspections.md +++ b/quality/inspections.md @@ -1,6 +1,15 @@ # Code Inspections & Tests -Code inspections are very important in order to maintain the same code quality throughout the application. The `Build` repository and package managers such as `composer` and `npm` contain all essential configuration files for the respective inspection tools. The framework and every module will be evaluated based on the defined code and quality standards. Only code that passes all code, quality and test standards are accepted. Updates and bug fixes also must follow the standards. +Code inspections are very important in order to maintain the same code quality throughout the application. The `Build` repository and package managers such as `composer` and `npm` contain all essential configuration files for the respective inspection tools. The framework and every module will be evaluated based on the defined code and quality standards. Only code that passes all code, quality and test standards is accepted. Updates and bug fixes also must follow the standards. + +## Summary + +The following tests must pass without errors, failures and warnings for successful code changes: + +* `php ./vendor/bin/phpstan analyse --autoload-file=phpOMS/Autoloader.php -l 9 -c Build/Config/phpstan.neon ./` +* `php ./vendor/bin/phpcs ./ --standard="Build/Config/phpcs.xml"` +* `npx eslint ./ -c Build/Config/.eslintrc.json` +* `php ./vendor/bin/phpunit -c tests/PHPUnit/phpunit_no_coverage.xml` ## How and what to test? @@ -18,6 +27,17 @@ The following testing requirements must be met: When testing it makes sense to test for the happy path/branch of how a method should work and to `try` and break things by trying to find inputs and paths which may lead to unexpected behavior and errors. +### Test locations + +* Application: tests +* Php framework: phpOMS/tests +* Modules: Modules/**/tests +* Js framework: jsOMS/tests +* C++ framework + tools: cOMS/tests +* Css framework: cssOMS/tests +* Configurations for tools: Build/Config +* Inspection script: Build/Inspection/inspection.sh + ### Unit tests The smallest/lowest level of testing are the unit tests. Unit tests should be implemented for models and framework methods. Every public function should be covered by at least one unit test. If a method has multiple branches every branch should be covered by a separate unit test. In some cases it might make sense to cover multiple branches in one unit test/test function, such a decision should however be made consciously. @@ -44,6 +64,28 @@ Every module must implement the following tests if applicable: You can find an example in the TestModule. +### Demo test + +The demo application is a simple way to check the overall functionality of the application and provide a user with a large amount of data for manual tests. + +A good way to setup a demo application with mostly randomly generated user input data is the **demoSetup** script which can be found in the repository https://github.com/Karaka-Management/demoSetup. + +The following command will create a demo application: + +```sh +php demoSetup/setup.php +``` + +In some cases code changes may require changes to the demo setup script (e.g. changes in the api, new modules). Since the demo setup script tries to simulate user generated data it takes some time to run. You may speed up the runtime by parallelizing the execution. However, this may use up 100% of your CPU and storage performance. + +```sh +php demoSetup/setup.php -a 0 +``` + +### UI tests + +While UI tests can be part of unit, integration or system tests the `cssOMS` repository also includes a simple test suit at http://127.0.0.1/cssOMS/tests/app which allows developers to test UI elements and check how they work. + ## Test documentation * every test must have a short test description @@ -110,7 +152,7 @@ The javascript testing is done with jasmine. The javascript testing directory is The js code base has a defined code style standard. The easiest way to check for most rules is to run eslint. ```sh -npx eslint jsOMS/ -c Build/Config/.eslintrc.json +npx eslint ./ -c Build/Config/.eslintrc.json ``` > Many IDEs allow to integrate eslint rules/configuration files for automatic checks in the editor @@ -144,18 +186,6 @@ php TestReportGenerator/src/index.php \ --version 1.0.0 ``` -## Demo setup +## References -A good way to setup a demo application with mostly randomly generated user input data is the **demoSetup** script which can be found in the repository https://github.com/Karaka-Management/demoSetup. - -The following command will create a demo application: - -```sh -php demoSetup/setup.php -``` - -In some cases code changes may require changes to the demo setup script (e.g. changes in the api, new modules). Since the demo setup script tries to simulate user generated data it takes some time to run. You may speed up the runtime by parallelizing the execution. However, this may use up 100% of your CPU and storage performance. - -```sh -php demoSetup/setup.php -a 0 -``` +[Development process](https://github.com/Karaka-Management/Docs/blob/master/Processes/Development.md) \ No newline at end of file