Add tests to majority of the files.

[bhavitsharma]

We have a lot of technical debt to pay, partly because there are little to no tests available. This makes development slow and cuber-some. There are currently 30 files with ~ 14K LOC in total, and yet there are no tests at all. We should start adding tests before implementing major new functionalities otherwise our technical debt will pile and this will severely impact future development.

We might also need to refactor a lot of code as some files > 1K LOC. (Please consider this as an umbrella bug)

[bhavitsharma]

I need to look at how closely is the GUI interlinked with the backend logic so we can add tests. Maybe the project maintainer can comment better. In the meanwhile, I will start by adding some basic testing functionality.

[rabite0]

Agreed, I've been thinking about how to do automated testing since there are way too many regressions with any major refactor/added feature and manually testing doesn't catch them all before pushing it to master...

need to look at how closely is the GUI interlinked with the backend logic so we can add tests. That's part of the reason I haven't tackled this at all, yet. (Apart from it being a lot of work). Many bugs seem to be more visual in nature, rather than easy to spot logic errors. Of the last 3 commits, 2 fix visual glitches:

16948dc origin/master fix tag toggling
f58982d fix file name length cutoff due to icons space
9e41b78 reduce flicker due to ticker

Although now that I think about it layout-y stuff like the second fix would be easy enough to spot with the right testing, so maybe I was just deceiving myself ;)

As far as the architecture goes, there's no separation ala MVC or anything like that, most widgets are self-contained and act on themselves by calling the appropiate methods. Some like ListView contain things like Files which does most of the heavy lifting, but even then there is some more coupling than there maybe should be, although some of that is for speed/efficiency's sake, too.

Then there are many widgets that contain and manage other widgets. They're mostly containers or custom views. In fact the UI is mostly built like a tree structure where widgets contain other widgets and so on. For example, it the main view looks somewhat like this:

TabView -> FileBrowser -> HBox -> ListView<Files>

Events like key input are propagated through the stack until something accepts them and then handled they're, although this is mostly custom-coded in the respective on_key handlers.