Step 0: focus, and don't get overwhelmed
There are several types of testing you can do. There's unit testing, acceptance testing, integration testing, test driven development (TDD), behavior driven development (BDD), acceptance test driven development (ATDD) etc. Don't get bogged down in terminology just yet. Focus on acceptance testing (see note), which roughly means to test the final version of your complete program. Once you get your feet wet with the simplest possible tests, you can start to look at the bigger world of software testing.
Note: Some folks may give advice to start with unit testing. That's
cool, too. That can be pretty easy if you're using a language with a
built-in unit testing framework. If not, installing a unit testing
framework can be a pain. This is why I recommend starting with
acceptance testing, because you don't need a fancy framework. All you need
is a way to call your program from a script or from another program. You
probably already have the tools to do that on your machine.
Step 1: create some test data
Create a folder, and in that folder put some dummy files. Make it so that you can easily find all of them (eg: their names all start with "f"), some of them (eg: some names end with a "Z", some don't), none of them (eg: none have the word "foobar" in their name). This is your test data. If your program can search sub-folders, create a few subfolders, too.
Step 2: create a simple test script
Write a test script using whatever scripting language you are comfortable with -- python, bash, powershell, etc. This script should call your program with parameters to search for files. For example, it should tell it where to search (eg: your new folder) and what to search for (eg: F*, *Z, foobar). Since you control how many files are in your test folder, you should know that a search for F* will return X files, searching for *Z should return Y files, and searching for foobar should return 0.
Note: you don't have to use a scripting language. Usually that's easier than creating a compiled test program. If you only know one language, though, use that language for now.
It really doesn't have to be any fancier than that -- a single script that calls your function, and then verifies that what it returns is what you expect. Do that for several different search criteria. Have your script print out a simple name for each test, and either "PASS" or "FAIL".
Step 3: add more test cases
As you're writing your first tests, you'll probably write tests for the simple cases. Think about edge cases -- testing the boundaries of what your code can do. Does your program accept an argument telling it where to search? Write a test where you don't give it the argument to make sure it prints an appropriate error message. Can you pass more than one argument? Arguments that are empty strings, or paths to folders that don't exist?
As you uncover bugs, add a test case before you fix the bug so that you can duplicate it. Fix the bug, and verify that your test case now passes. As you add new features you can do the same thing -- add a test before adding the new feature. It should fail, until you get that feature working. This is known as TDD, or Test Driven Development.
Step 4: learn
Once you're comfortable with how that works, you can start looking at other tools to make this easier. For example, cucumber or the robot framework are good choices for acceptance testing, but there are many, many others.
