Re: Ambitious KDE Goal: Briding the Gap
On Sun, Aug 20, 2017 at 01:39:59PM +0200, Jos van den Oever wrote: > I feel like I should join in as well in pitching ambitious ideas for KDE. Can you please submit this to goal settings phabricator board just like other ideas? Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Ambitious KDE Goal: Briding the Gap
On Sunday, August 20, 2017 2:27:44 PM CEST Adriaan de Groot wrote: > On Sunday 20 August 2017 13:50:54 Jos van den Oever wrote: > > Here is a nice example project that has a features/ folder. > > > > https://github.com/acmcarther/cucumber/tree/master/examples/calculator/ > > features > > Also, Kevin Ottens gave a talk at Akademy once about using Cucumber in > testing of Zanshin; so software craftsmanship implies also well-documented > and well- described software. I like it, it ties in also with the > (smaller?) ambition from the documentation / wiki bof. Nice. I missed that talk. Akademy is so humongous. You probably mean this one: https://conf.kde.org/en/Akademy2014/public/events/88 https://ervin.ipsquad.net/slides/talks/ak2014-agile-rescue/#/37 Zanshin has 49 feature files. The first one was added in April 2014. CGit has highlighting for them which makes the structure clear. https://cgit.kde.org/zanshin.git/tree/tests/features/zanshin/features/workday/ workday-display-completed.feature This method is translated. I'm working a project where with Dutch feature files. Cheers, Jos signature.asc Description: This is a digitally signed message part.
Re: Ambitious KDE Goal: Briding the Gap
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 signature.asc Description: This is a digitally signed message part.
Ambitious KDE Goal: Briding the Gap
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 signature.asc Description: This is a digitally signed message part.
