Unit tests for os.scandir/scantree a directory I wrote my first series of test for this simple function:

def map_directory(self, path='', method='recursive'):
    """
        scan the given path
            method -&gt; recursive (all levels) or single (first level only)
    :param method: string
    :param path: string
    :return: generator
    """
    if not path:
        path = self.path

    if method == 'recursive':
        f = self.scan_tree
    elif method == 'single':
        f = os.scandir
    else:
        raise BullShitError('please enter a valid scanning method : {} is BS'
                            .format(method))
    return f(path)

def scan_tree(self, path=''):
        """
            recursively yield DirEntry objects for given directory.
        :return: generator
        """
        if not path:
            path = self.path

        for entry in (d for d in os.scandir(path) if FileSystemManager.is_readable(d.path) is True):
            try:
                if entry.is_dir(follow_symlinks=False):
                    yield entry
                    yield from self.scan_tree(entry.path)
                else:
                    yield entry
            except PermissionError:
                logger.warning('this entry raised an error : {}'.format(entry.path))
                continue


Tests :

import os
from django.test import TestCase

from packages.system.filesystem import FileSystemManager
from packages.system.local_dirs import user_home


class FileSystemManagerTests(TestCase):

    @classmethod
    def setUpClass(cls):
        cls.test_dir = os.path.join(user_home, 'test/a/b/c')

        os.makedirs(cls.test_dir, 0o755, exist_ok=True)
        cls.fl = FileSystemManager(cls.test_dir)

    @classmethod
    def tearDownClass(cls):
        pass

    def test_map_directory_returns_only_direntry_objects(self):
        """
            map_directory() returns only DirEntry objects in the returned generator
        """
        mapping = self.fl.map_directory()
        for obj in mapping:
            self.assertIsInstance(obj, os.DirEntry)

    def test_map_directory_returns_generator(self):
        """
            map_directory() returns a generator
        """
        from typing import Generator
        self.assertIsInstance(self.fl.map_directory(), Generator)

    def test_map_directory_recursive_method(self):
        """
            map_directory() recursive returns a, b, c
        """
        mapping = self.fl.map_directory(os.path.join(user_home, 'test'))
        self.assertEqual(len(tuple(mapping)), 3)

    def test_map_directory_single_method(self):
        """
            map_directory() single method returns a
        """
        mapping = self.fl.map_directory(os.path.join(user_home, 'test'), 
                                        method='single')
        self.assertEqual(len(tuple(mapping)), 1)


I then have 3 main questions:


Is this "over tested"?
Does testing for only the length of the generator suffice for a proper test?
Should I ignore this function which is straightforward enough and center the focus of my tests on the self.scan_tree method?


Any other comments are welcomed, thanks.
General


You use what seems to be a non-standard docstring style. That's fine, but it's actually quite close to the RST / Sphinx syntax. An overview of the various styles can be found here. It's a good idea to pick one you like and stick to it, or to simply enforce your own style, but mixing styles will certainly result in confusion. 'Why is this RST not being interpreted correctly?!' or 'Why does this perfectly readable docstring have random pieces of RST syntax thrown in?'
These two lines:

if not path:
    path = self.path


Should be a red flag. Let's get this straight. There's a path associated with self, and a custom path can be passed as a parameter to the method. This means that map_directory() should either be @staticmethod'ed, or self.path should not exist. Without context, there's no way of telling which is the right solution, but this is clearly wrong.
When you raise the exception (by the way, BullShitError, really?) you tell the developer what went wrong (good) but don't give them a list of valid options (bad). Not everyone is going to read through the documentation immediately when they get an exception. To a reasonable extent, exception messages should tell the developer exactly what to do to prevent the exception in the future.


Questions


Barely. The only thing I don't think is worth testing is whether the return type is a generator. The other tests look sane and useful, so keep them.
In a controlled testing environment, you might as well have a tuple of the entries and check if the method call matches the expected results. 
That's impossible to tell if you don't show us what self.scan_tree() actually does.