Setup jest and fix test and add sample files

Author: Emil Kais

jest.config.js

@@ -0,0 +1,7 @@
+module.exports = {
+  preset: "ts-jest",
+  testEnvironment: "node",
+  testMatch: [
+    "<rootDir>/**/*.(test|spec).(ts|js)",
+  ],
+};

nodes/Markitdown/Markitdown.node.ts

@@ -47,29 +47,23 @@ export class Markitdown implements INodeType {
 
 				const binaryData = this.helpers.assertBinaryData(i, inputBinaryField);
 
-				// Step 2: Write the file to a tmp directory
 				const inputTmpFile = await tmpFile({
 					prefix: 'n8n-markitdown-input-',
 					postfix: binaryData.fileName
 				});
 				await fsPromise.writeFile(inputTmpFile.path, Buffer.from(binaryData.data, 'base64'));
 
-				// Step 3: Run markitdown command on the tmp file
 				const outputTmpFile = await tmpFile({
 					prefix: 'n8n-markitdown-output-',
-					postfix: '.md'
+					postfix: '.md',
 				});
 
-        // Build the markitdown command
         const command = `markitdown "${inputTmpFile.path}" -o "${outputTmpFile.path}"`.trim();
 
-        // Execute markitdown
-        await execPromise(command);
+				await execPromise(command);
 
-        // Read the output file
         const outputContent = await fsPromise.readFile(outputTmpFile.path, 'utf-8');
 
-        // Prepare the output item
         const newItem: INodeExecutionData = {
           json: {
 						data: outputContent

nodes/Markitdown/test/Markitdown.test.ts

@@ -0,0 +1,73 @@
+import { IExecuteFunctions } from 'n8n-workflow';
+import { promises as fsPromise } from 'fs-extra';
+import { Markitdown } from '../Markitdown.node'
+import * as path from 'path';
+
+describe('Markitdown Node', () => {
+	let nodeInstance = new Markitdown()
+
+	const sampleFilePath = path.join(__dirname, 'test.docx');
+  let sampleFileBuffer: Buffer;
+	beforeAll(async () => {
+    // Create a real sample file for testing
+    sampleFileBuffer = await fsPromise.readFile(sampleFilePath);
+	})
+	afterAll(async () => {
+    // Clean up the sample file
+    try {
+			jest.restoreAllMocks(); // Reset mocks after each test
+      await fsPromise.unlink(sampleFilePath);
+    } catch (error) {
+      // Ignore if already deleted
+    }
+  });
+
+	it('should convert a document to markdown', async () => {
+		// jest.spyOn(fsPromise, 'readFile').mockResolvedValue(``)
+		// jest.spyOn(fsPromise, 'writeFile').mockResolvedValue()
+    // Create a mock execution context with real binary data
+    const mockExecuteFunctions: IExecuteFunctions = {
+      getInputData: () => [{
+        json: { filename: 'test-sample.docx' },
+        binary: {
+          data: {
+            fileName: 'test-sample.docx',
+            mimeType: 'application/vnd.openxmlformats-officedocument.wordprocessingml.document',
+            data: sampleFileBuffer.toString('base64')
+          }
+        }
+      }],
+      getNodeParameter: () => 'data',
+      helpers: {
+        assertBinaryData: (itemIndex: number, field: string) => {
+          const items = mockExecuteFunctions.getInputData();
+          if (itemIndex >= items.length) {
+            throw new Error(`Item index ${itemIndex} out of bounds`);
+          }
+
+          const item = items[itemIndex];
+          if (!item.binary || !item.binary[field]) {
+            throw new Error(`Binary data not found for field ${field}`);
+          }
+
+          return item.binary[field];
+        }
+      },
+      continueOnFail: () => false
+    } as unknown as IExecuteFunctions;
+
+    // Execute the node function
+    const result = await nodeInstance.execute.call(mockExecuteFunctions);
+
+    // Verify the results
+    expect(result).toHaveLength(1);
+    expect(result[0]).toHaveLength(1);
+		const readSample = await fsPromise.readFile(path.join(__dirname, 'test.md'))
+    expect(result[0][0].json.data).toBe(readSample.toString());
+
+    // Verify the command execution
+    expect(nodeInstance.execute).toHaveBeenCalledTimes(1);
+    // expect(nodeInstance.execute.calls[0][0]).toMatch(/markitdown ".*n8n-markitdown-input-test-sample.docx" -o ".*n8n-markitdown-output-.md"/);
+	}, 30000)
+
+});

nodes/Markitdown/test/test.docx

@@ -0,0 +1,25 @@
+AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation
+
+Qingyun Wu , Gagan Bansal , Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Awadallah, Ryen W. White, Doug Burger, Chi Wang
+
+# Abstract
+
+AutoGen is an open-source framework that allows developers to build LLM applications via multiple agents that can converse with each other to accomplish tasks. AutoGen agents are customizable, conversable, and can operate in various modes that employ combinations of LLMs, human inputs, and tools. Using AutoGen, developers can also flexibly define agent interaction behaviors. Both natural language and computer code can be used to program flexible conversation patterns for different applications. AutoGen serves as a generic framework for building diverse applications of various complexities and LLM capacities. Empirical studies demonstrate the effectiveness of the framework in many example applications, with domains ranging from mathematics, coding, question answering, operations research, online decision-making, entertainment, etc.
+
+# Introduction
+
+Large language models (LLMs) are becoming a crucial building block in developing powerful agents that utilize LLMs for reasoning, tool usage, and adapting to new observations (Yao et al., 2022; Xi et al., 2023; Wang et al., 2023b) in many real-world tasks. Given the expanding tasks that could benefit from LLMs and the growing task complexity, an intuitive approach to scale up the power of agents is to use multiple agents that cooperate. Prior work suggests that multiple agents can help encourage divergent thinking (Liang et al., 2023), improve factuality and reasoning (Du et al., 2023), and provide validation (Wu et al., 2023).
+
+## d666f1f7-46cb-42bd-9a39-9a39cf2a509f
+
+In light of the intuition and early evidence of promise, it is intriguing to ask the following question: how can we facilitate the development of LLM applications that could span a broad spectrum of domains and complexities based on the multi-agent approach? Our insight is to use multi-agent conversations to achieve it. There are at least three reasons confirming its general feasibility and utility thanks to recent advances in LLMs: First, because chat optimized LLMs (e.g., GPT-4) show the ability to incorporate feedback, LLM agents can cooperate through conversations with each other or human(s), e.g., a dialog where agents provide and seek reasoning, observations, critiques, and validation. Second, because a single LLM can exhibit a broad range of capabilities (especially when configured with the correct prompt and inference settings), conversations between differently configured agents can help combine these broad LLM capabilities in a modular and complementary manner. Third, LLMs have demonstrated ability to solve complex tasks when the tasks are broken into simpler subtasks. Here is a random UUID in the middle of the paragraph! 314b0a30-5b04-470b-b9f7-eed2c2bec74a Multi-agent conversations can enable this partitioning and integration in an intuitive manner. How can we leverage the above insights and support different applications with the common requirement of coordinating multiple agents, potentially backed by LLMs, humans, or tools exhibiting different capacities? We desire a multi-agent conversation framework with generic abstraction and effective implementation that has the flexibility to satisfy different application needs. Achieving this requires addressing two critical questions: (1) How can we design individual agents that are capable, reusable, customizable, and effective in multi-agent collaboration? (2) How can we develop a straightforward, unified interface that can accommodate a wide range of agent conversation patterns? In practice, applications of varying complexities may need distinct sets of agents with specific capabilities, and may require different conversation patterns, such as single- or multi-turn dialogs, different human involvement modes, and static vs. dynamic conversation. Moreover, developers may prefer the flexibility to program agent interactions in natural language or code. Failing to adequately address these two questions would limit the framework’s scope of applicability and generality.
+
+Here is a random table for .docx parsing test purposes:
+
+|  |  |  |  |  |  |
+| --- | --- | --- | --- | --- | --- |
+| 1 | 2 | 3 | 4 | 5 | 6 |
+| 7 | 8 | 9 | 10 | 11 | 12 |
+| 13 | 14 | 49e168b7-d2ae-407f-a055-2167576f39a1 | 15 | 16 | 17 |
+| 18 | 19 | 20 | 21 | 22 | 23 |
+| 24 | 25 | 26 | 27 | 28 | 29 |

nodes/Markitdown/test/test.md

@@ -28,7 +28,8 @@
     "format": "prettier nodes --write",
     "lint": "eslint nodes package.json",
     "lintfix": "eslint nodes package.json --fix",
-    "prepublishOnly": "pnpm build && pnpm lint -c .eslintrc.prepublish.js nodes package.json"
+    "prepublishOnly": "pnpm build && pnpm lint -c .eslintrc.prepublish.js nodes package.json",
+    "test": "jest"
   },
   "files": [
     "dist"
@@ -41,6 +42,8 @@
   },
   "devDependencies": {
     "@types/fs-extra": "^11.0.4",
+    "@types/jest": "^29.5.14",
+    "@types/mocha": "^10.0.10",
     "@types/node": "^22.13.8",
     "@typescript-eslint/parser": "^7.15.0",
     "eslint": "^8.56.0",
@@ -54,9 +57,15 @@
     "n8n-workflow": "*"
   },
   "dependencies": {
+    "@n8n/di": "^0.2.0",
     "child_process": "^1.0.2",
     "fs-extra": "^11.3.0",
-    "tmp-promise": "^3.0.3"
+    "jest": "^29.7.0",
+    "jest-mock": "^29.7.0",
+    "jest-mock-extended": "4.0.0-beta1",
+    "nock": "^14.0.1",
+    "tmp-promise": "^3.0.3",
+    "ts-jest": "^29.2.6"
   },
   "pnpm": {
     "overrides": {