FileManager has a lot of userinput, in order to make the program test-able it needs methods that operate on the files to be independent of scanners.

So that it can be called easily and factored out of methods that change things

It's a very similar action where move has an extra step after copying.

You could make a cut method that calls the move method and then deletes the file that was moved from its original location.

As written (checking for input to be move to do one other task) would be the same amount of work. It may make future changes

to move and copy be easier to change if they were less integrated.

- add the idea of a _current folder_? -- we would need a cd type command that moved us into a certain folder

- how would you add a _change folder_ command? -- we can take a file path and then need a field to store the current path we're on and

be able to move forward and backward on it

- how would you add a command to display the contents of a file? you'd need the ability to read the file's text and store that before printing to console

- how would you change _list_ to show the difference between files and folders? string formatting

- how could you clean up some of the code by using an _enum_ instead of strings for the commands?

an enum would clean up some of the console variables and make a cleaner switch statement possible??

- how would you use the _FileOperator_ class to test the _FileOperator_ class?

Creating an instance of console and passing it to a new instance of file operator would let you call methods of the

class. You could make instances of file's etc for testing

you could test the FileOperator class with the above method

Tests that include user I/O would need to be tested through use rather than with test methods

FileManager which has a lot of console scanner waiting for input

I didn't notice any..

Write tests that cover all of the FileOperator methods

By having a single Console, it can clean up repeated code