Improvements in testcases

[lazysegtree]

The part you want to Enhancement
Test cases to cover at least some part of code that can be covered via test case, and test cases to cover critical portions, or portions where bugs could be easily introduced by new changes.

Why it is necessary to enhancement
To make sure features work as intended and that future changes/refactoring do not introduce bugs.
Otherwise regressions caused by changes will be not be caught.

Additional context
While writing tests may require upfront effort, it will save time and resources in the long run by making the codebase easier to maintain and extend.
Well-tested project -> More trust among users and contributors, potentially leading to more contributions and a larger user base.

Edit - I realised, that there already are some testcases. Updated Title to account for that.

[lazysegtree]

Since this is a terminal file manager, there are many things that are hard to test via unit test, or even integration test. But we should still have test cases for what we can cover.

And it will take a while to decide the testing framework and testing plan, and eventual implementation of tests.

I will try to help out as per my availability.

[lazysegtree]

Also, I think we should be using lint, goimports, golangci-lint during build process.

[lazysegtree]

One idea I had to is to have some sort of testcase that can make sure superfile stays performant, and any new changes doesn't brings it down.
Performance related issue - #124

[lazysegtree]

Just realised that there are some testcases (string_functions_test.go), so "There are no test cases" is false. I will try to come with some exact testcases that should be added.

[yorukot]

I agree that superfile needs more test cases, not only to identify errors and bugs but also to evaluate its performance.

[lazysegtree]

My current idea is this

• We can move all the file operations into an abstraction layer, via an interface. In source code we would use an actual implementatoin, that make os calls. In testcases, we would have a mock File system using some in memory file system or something, so we should be able to test all sorts of operations and error cases.
• Need to mock filesystem for all operations - Copy/Paste/Stat/Walk/Recycle Bin, etc..
• We could create a mock 'bubbletea' for tests, and call model.Update, model.View in tests cases, and validate behaviour of model
• For us to be able to structure tests across files correctly , the code has to be structured well too. Huge refactoring needed
• We could make internal.Model a interface, and use a mock implementation in tests - We could verify some functionalities of the layer above our model ( the bubbletea layer )