Ambitious KDE Goal: Briding the Gap

[Jos van den Oever]

Here is a nice example project that has a features/ folder.

https://github.com/acmcarther/cucumber/tree/master/examples/calculator/
features

On Sunday, August 20, 2017 1:39:59 PM CEST Jos van den Oever wrote:
> I feel like I should join in as well in pitching ambitious ideas for KDE.
> 
> For mortals, it is hard to understand how KDE applications work. It is very
> hard to get into KDE coding. There is a lot of implicit knowledge in the
> code base. I think we should make this better by having testable high level
> descriptions of applications.
> 
> There is a lot of testing code in KDE applications and it often follows the
> test driven development approach where a situation is presented (Given), and
> action described (When) and an outcome verified (Then).
> 
> These functional descriptions from the tests can go into their own files.
> This would give simple files that any user can read and comment on. The
> same description is used in the text and this way, the desired features are
> linked to the tested features. The .feature files are stored in git and a
> change in software behavious is easily discovered.
> 
> These .feature files are easy to read and should stay the same even after
> large refactorings (Qt6!). We can make insightful what part of the features
> has tests and what part of the tests passes.
> 
> This method is used in projects where new developers should be able to jump
> in quickly. It makes it easy to add new features in a structured way: you
> start with the .feature file, then write tests and then the implementation.
> 
> It works the other way around too. There's lots of code lying around where
> it is not obvious that it is still needed. If it is not covered by tests or
> features, then it can go, or a feature of the code is not documented.
> 
> Here is a simple example of a .feature in the Gherkin language.
> 
> ===
> Feature: About box
> 
>   Scenario: Show the about box menu
>     Given that Dolphin has started
>     And it is showing the main window
>     Then a user action for showing the about box is present
> 
>   Scenario:
>     Given that Dolphin has started
>     And it is showing the main window
>     When the user activates the about action
>     Then the About dialog is shown
> ===
> 
> This is user readable and so users can more easily understand how an
> application is supposed to behave. They do not need to understand the code
> that implements these features. People that would like to document KDE
> applications can read the .feature files to write their documentation.
> 
> This helps to communicate our prinicples to users. We can describe the
> behaviour of telemetry in a .feature file. It will describe opt-in
> telemetry: "When the application starts with default values Then the option
> telemetry is turned off".
> 
> Working with these .feature files is a new thing for desktop software, but
> one that makes the workings of our software more relatable for users. They
> will value this and see our work less as magic and will understand the
> value of an open project. They might even be led down to the path of being
> a developer eventually.
> 
> Best regards,
> Jos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20170820/e66b5ef6/attachment.sig>