baudren / NoteOrganiser

Scientific Note Taking
MIT License
13 stars 6 forks source link

Create Robot Framework test suite to serve as specifications #75

Open baudren opened 9 years ago

baudren commented 9 years ago

Note Organiser has still a reasonable size in terms of features, so while we have them all under control, it would be a nice thing to actually write them down to test them.

RobotFramework has actually a very nice interface, and allows to write the specifications as natural language, and implement the testing behind.

I have drafted the idea in the new branch, robotframework. Right now, the tests are not called at all. You can test them (they will fail, because nothing is implemented), by install robot framework, and running pybot ., or python -m robot.run . inside the noteorganiser/tests/ directory. The application will open, wouhou, and close. That's about it, for now.

The underlying libraries are separated into PysideLibrary.py, which could in term become a real Robot Framework package. I will put there all the generic Pyside functionnalities, screenshot, open/close, select based on type, etc... All the relevant code for testing NoteOrganiser itself is in NoteOrganiserTesting.py, which serves as a frontend for all the code in keywords/blabla.py.

Right now, the .robot files cover the first time setup, and some of the library interaction. Only the file resource.robot is imported by the test suite (all files defining some *** Test Cases ***). In natural.robot, I store right now mappings from natural sentences to more low-level calls.

Things to do include, among other things:

The goal of this is not necessarilly to get rid of the existing tests - some measure of unit testing, also for the UI, is a good thing. The idea is simply to cover all the high-level functionalities, and ensure that they work/continue to work throughout the development.

baudren commented 9 years ago

As the roadmap changed (switching technologies to QML + PyOtherSide), the scope of this issue has also changed.

I left only the specifications part to write from the previous post. There is no point in writing the actual implementation of the tests, but simply have the actual functionalities written down to keep in mind during the refactoring.

These specifications should be descriptive enough, but not rely on the current user interface (for instance, the opening screen to the library might disappear to be replaced by a column to browse the notebooks). For instance:

Given I am previewing a notebook
When I select a tag
Then I should see only the relevant posts

But not

Given I am on the preview tab
When I click on a tag
Then I should see only the relevant posts
baudren commented 9 years ago

The current list of specifications grows steadily. It can be found in these five files, so far: https://github.com/baudren/NoteOrganiser/blob/robotframework/noteorganiser/tests/first_time.robot https://github.com/baudren/NoteOrganiser/blob/robotframework/noteorganiser/tests/library.robot https://github.com/baudren/NoteOrganiser/blob/robotframework/noteorganiser/tests/organizing.robot https://github.com/baudren/NoteOrganiser/blob/robotframework/noteorganiser/tests/posting.robot https://github.com/baudren/NoteOrganiser/blob/robotframework/noteorganiser/tests/preview.robot

What is lacking to Robot Framework is a nice way of visualising this kind of information, summarized in one nice webpage. Their doctest tool produces something not so readable.

Anyway, any comment on some existing functionality that I missed, or new functionality that we discussed and that I forgot to add, please fire away. I think that it is pretty close to being finished, though.