-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
* Creation of .gitignore file * Addition of motivation, conventions, technology and frameworks to README.md
- Loading branch information
1 parent
b70c5d9
commit e7725f2
Showing
2 changed files
with
54 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
.DS_Store | ||
.idea |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,52 @@ | ||
# mdd | ||
# Model-driven Software Engineering | ||
This test case generator produces test cases from plantUML diagrams. | ||
|
||
# Motivation | ||
The implementation of user requirements often deviates from the specification of the same user requirements. | ||
Individual work, teamwork, and collaboration between teams can produce such a divergence. | ||
For example, requirements may be misinterpreted or overlooked. | ||
Teamwork, especially with multiple teams, causes interface errors. | ||
For example, subsystems of the same product may use conflicting technologies or conflicting data formats. | ||
|
||
Our test case generator detects deviations at an early stage: | ||
The test case generator derives test cases directly from the specification. | ||
If the implementation fulfills these test cases, then the implementation fulfills the specification. | ||
If the implementation does not fulfill these test cases, the implementation deviates from the specification. | ||
With our test case generator, developers can quickly uncover inconsistencies, fix them, and save costs. | ||
|
||
# Conventions | ||
## Repository language | ||
English | ||
|
||
## Review process | ||
A pull request addresses a single issue. | ||
|
||
A pull request must be approved by two reviewers. | ||
|
||
A pull request is squashed before the merge. | ||
|
||
## Naming Conventions: Issues, branches, pull requests, squashed merge commits | ||
Issues describe project work such as tasks, bugs, and feature requests. | ||
Example: ```Implement task XYZ``` | ||
|
||
The branch name follows the issue name. | ||
The automatically generated issue ID is succeeded by the issue name in lowercase letters, with hyphens separating multiple words. | ||
Example: ```#1-implement-task-xyz``` | ||
|
||
The pull request name is the issue name plus the issue id. | ||
Example: ```Implement task XYZ (Issue #1)``` | ||
|
||
The squashed merge commit name is the issue name plus the issue id plus the pull request id. | ||
Example: ```Implement task XYZ (Closes #1) (PR #2)``` | ||
|
||
If a pull request addresses several issues, the pull request name is a summary of the issues plus the issue ids. | ||
The squashed merge commit name is a summary of the issues plus the issue ids plus the pull request id. | ||
Example pull request: ```Initial Setup (Issue #1, Issue #2, Issue #3)``` | ||
Example squashed merge commit: ```Initial Setup (Closes #1, Closes #2, Closes #3) (PR #2)``` | ||
|
||
# Technology and frameworks | ||
## PlantUML | ||
Website: [www.plantuml.com](www.plantuml.com) | ||
|
||
## Cucumber | ||
Website: [https://cucumber.io](https://cucumber.io) |