Mocking FS..? Not really

I have came back to my problem. Mocks in jest. Specifically, for fs. I have learned a lot from my struggles. I learned better how different modules connect to each other. What I should expect of certain functions. What was the idea behind the examples I found.

Concretely, in code

Examples of fs mocks that I have found used them for different kind of functions as compared to mine. I saw one with passing an object, however my readFile function only takes in a file name. Here's how it is right now, by the way:

function readFile(file) {
    try {
        if (file.match(".*(.txt|.md)$")) {
            //read the file
            let fullText = fs.readFileSync(file, "utf8");
            //formatting if it's an .md file
            if (file.match(".*(.md)$")) {
                //replacing strings
                fullText = fullText.replace(/_ /g, "<i>");
                fullText = fullText.replace(/ _/g, "</i>");
                fullText = fullText.replace(/__ /g, "<b>");
                fullText = fullText.replace(/ __/g, "</b>");
                fullText = fullText.replace(/### /g, "<h3>");
                fullText = fullText.replace(/ ###/g, "</h3>");
                fullText = fullText.replace(/## /g, "<h2>");
                fullText = fullText.replace(/ ##/g, "</h2>");
                fullText = fullText.replace(/# /g, "<h1>");
                fullText = fullText.replace(/ #/g, "</h1>");

                fullText = fullText.replace(/---/g, "<hr>");
            }
            //future functionality of choosing the element you want to use
            let element = "p";

            //divide text into paragraphs
            const paragraphs = fullText.split(/\r?\n\r?\n/);

            let title = paragraphs[0];
            let htmlParagraphsArray = [];

            //put them all into an array
            for (let i = 0; i < paragraphs.length; i++) {
                if (i == 0)
                    //only the first paragraph is the title
                    htmlParagraphsArray.push(`<h1>${title}</h1>`);
                else {
                    htmlParagraphsArray.push(
                        `<${element}>${paragraphs[i]}</${element}>`,
                    );
                }
            }

            //put them all into a single string, every paragraph starts from a new line
            let texts = htmlParagraphsArray.join("\n");
            return { texts: texts, title: title };
        }
    } catch (e) {
        throw `Error in reading file ${file}, ${e}`;
    }
}

As you can see, I have a bunch of things happening at the same time in a single funciton. I now understand more what modular functions should look like. And why they should be that way.

I'm not sure if I can still properly use the fs mock though. I don't know if I can replace the fs.readFileSync with the mock fs. I would imagine that's how it should work, but I don't actually know.

I could restructure my whole code to match the style where I'd pass an object, but that wouldn't solve the fs mocking problem. I think I'm just missing a basic concept here.

Long story short, I couldn't make half of the tests I wanted work because of fs. After I removed some of them, I apparently did something else wrong and I couldn't pass my own actions' checks. In the end I just copied an older version from main to reset my problematic code. I also realised I couldn't really test a function I tried to test, since it went on calling other ones, which would eventually get to one which shouldn't work anyway. That would fail the test I set up, which I didn't understand at first.

Actions

Learning about github actions was useful. It wasn't a difficult process to set up, but it explained a lot what I saw in other projects. It connects everything together. You just run tests and they have to pass - it's that simple.

Other people's tests

As I was looking at other people's code I noticed a totally different structure. I also found it difficult to find something to contribute to, seemed that everyone had all their functions covered.

I might have to restructure my whole code system to match testing expectations. It won't be just me guessing how to divide things by their functionality anymore - now I know what a testing function wants.