Skip to content

automatic tests #697

@sorokin

Description

@sorokin

I have perhaps quite unusual feature request. I would like edb to have automatic tests.

I did some testing a while ago. I tested edb under valgrind, under address sanitizer and with debug mode of libstdc++. As the result I found a few bugs. I have fixes for some of them and I'm going send patches when they are ready.

My problem is that I believe that fixes without tests are fragile. Nothing prevent the same code to break in the future again during some refactoring. That's why I would like edb to get some automatic tests.

I can imagine two types of automatic tests in edb:

  1. Tests that uses edb as a library. They don't do any UI. They just initialize debugger and call some functions of it. Like "start this program for debugging", "set break point to this address", "run and wait until break point is hit", and so on. The programs to run can be some minimal (a few kb in size) programs designed to check the specific features of the debugger. Which test framework to use for these tests doesn't matter much in my opinion and can be decided later.
  2. Tests that test edb as whole. Qt has ability to simulate clicks and user actions in the application (https://doc.qt.io/qt-5/qttestlib-tutorial3-example.html). I have never used them, but at first glance they looks pretty straightforward. These tests are primary designed to test UI. In theory they can be used to test debugger logic as well, but if we have many of them I expect them to run much slower than tests 1.

I believe we can do either 1 or 2 or both. At least for my use case either option is OK.

I think I can spend some time implementing these tests. But before I start I would like to ask your opinion.

  • What type of tests do you think should be implemented? 1 or 2 or both or perhaps you have some other ideas?
  • Tests EDB scrolls by bytes, not instruction #1 require edb to be split into a library part and a UI part. Looking at edb source code it is not apparent to me which translation unit should go to which part. Do you think making this split is feasible. If not perhaps just tests 2 should be implemented.

At the moment I'm currently leaning toward implementing option 2.


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions