@@ -214,6 +214,51 @@ All loaders follow TSV best practices with caching, file change detection, and t
214214
215215## Testing Standards
216216
217+ ### No Mocks or Patches Policy
218+ ** NEVER use mocks, patches, or similar test doubles.** Tests should use real implementations and real data.
219+
220+ ``` python
221+ # ✅ Good: Test with real data loaders and real logic
222+ def test_get_gene_info ():
223+ result = get_gene_info(" Atu0001" )
224+ assert result[" locusId" ] == " Atu0001"
225+
226+ # ❌ Bad: Using mocks or patches
227+ @patch.object (fitness_loader, ' get_gene_info' )
228+ def test_get_gene_info_mocked (mock_get ): # DON'T DO THIS
229+ mock_get.return_value = {' locusId' : ' Atu0001' }
230+ ```
231+
232+ ### Conservative Error Handling in Tests
233+ Be very conservative with try/except in tests. If something fails, we want to know about it immediately.
234+
235+ ``` python
236+ # ✅ Good: Let exceptions bubble up
237+ def test_gene_lookup ():
238+ result = get_gene_info(" Atu0001" ) # Will fail clearly if broken
239+ assert " locusId" in result
240+
241+ # ❌ Bad: Hiding failures with try/except
242+ def test_gene_lookup ():
243+ try :
244+ result = get_gene_info(" Atu0001" )
245+ except Exception :
246+ assert False # Doesn't show what actually failed
247+ ```
248+
249+ ### No Async/Batch Processing
250+ ** NEVER use async/await or batch processing.** MCP tools are called by LLM agents (Claude, Goose) that expect synchronous responses.
251+
252+ ``` python
253+ # ✅ Good: Synchronous tool functions
254+ def get_gene_info (gene_id : str ) -> Dict[str , Any]:
255+ return fitness_loader.get_gene_info(gene_id)
256+
257+ # ❌ Bad: Async functions break MCP protocol
258+ async def get_gene_info_async (gene_id : str ) -> Dict[str , Any]: # DON'T DO THIS
259+ return await fitness_loader.get_gene_info_async(gene_id)
260+ ```
261+
217262### Test Categories
218263Use pytest markers for different test types:
219264
@@ -349,6 +394,41 @@ gene_id = row[0] # Get gene ID from first column
349394
350395---
351396
397+ ## GitHub Issue Workflow
398+
399+ When working on GitHub issues, follow this systematic approach:
400+
401+ 1 . ** Create and checkout linked branch** : ` git checkout -b issue-{number}-{short-description} `
402+ 2 . ** Bring feature branch up to date with main** : Feature branches MUST always be brought up to date with main before completing work
403+ 3 . ** Work on implementation** following all guidelines in this document
404+ 4 . ** Test thoroughly** with comprehensive test suite
405+ 5 . ** Run ` make all ` until all problems are fixed** - This is mandatory before completion
406+ 6 . ** Commit and push** when complete
407+ 7 . ** Create pull request** that auto-closes the issue when merged
408+
409+ ### Branch Naming Convention
410+ - Format: ` issue-{number}-{short-description} `
411+ - Examples: ` issue-21-metadata-registry ` , ` issue-22-data-redundancy `
412+ - Use kebab-case for descriptions
413+ - Keep descriptions concise but descriptive
414+
415+ ### Task Completion Requirements
416+ ** ALWAYS run ` make all ` before considering any task complete.** This command runs the full validation pipeline:
417+ - Code formatting and linting
418+ - Type checking
419+ - Comprehensive test suite
420+ - Coverage verification
421+ - Integration testing
422+ - MCP protocol validation
423+
424+ ** Repeat ` make all ` until zero errors remain.** Only then is a task ready for commit and push. This ensures:
425+ - No regressions introduced
426+ - All code quality standards met
427+ - Full functionality preserved
428+ - Ready for production deployment
429+
430+ ---
431+
352432## Future Development Guidelines
353433
354434### Extensibility Patterns
0 commit comments