diff --git a/CODING_STANDARDS.md b/CODING_STANDARDS.md
index ab0fe5445..400e8f51a 100644
--- a/CODING_STANDARDS.md
+++ b/CODING_STANDARDS.md
@@ -34,6 +34,40 @@
 
 Remember, these rules are here to make our codebase harmonious. If something doesn't fit perfectly, let's chat about it. Happy coding! 🚀
 
+
+## Tests 
+
+- Add tests for any new functionality or meaningful changes. If code is added, removed, or significantly modified, corresponding tests should be updated or created.
+ 
+- Prioritise high-value tests over maximum coverage. Focus on testing behaviour that is critical, complex, or likely to break—don’t chase coverage numbers for their own sake.
+
+- Write behaviour-driven tests, not implementation-driven ones. Tests should validate real expected output and observable behaviour, not internal details or mocked-out logic unless absolutely necessary.
+
+- Minimise mocking unless it meaningfully increases clarity or isolates external dependencies. Prefer real flows where practical; only mock external services, slow systems, or non-deterministic behaviour.
+
+- Keep tests readable and maintainable. Optimise for clarity over cleverness. Name tests descriptively, keep setup minimal, and avoid unnecessary abstraction.
+
+- Aim for tests that fail usefully. When a test fails, it should clearly indicate what behaviour broke and why.
+
+- Cover both the “happy path” and the realistically problematic paths. Validate expected success behaviour, but also validate error handling, edge cases, and degraded-mode behaviour when appropriate.
+
+- Ensure tests are deterministic and reproducible. No randomness, timing dependencies, or environment-specific assumptions without explicit control.
+
+- Avoid overfitting tests to current behaviour if future flexibility matters. Only assert what needs to be true, not incidental details.
+
+- Use consistent patterns and helper utilities where they improve clarity. Prefer shared test utilities over copy-pasted setup code, but only when it actually reduces complexity.
+
+- Tests should be fast enough to run continuously. Avoid long-running operations unless absolutely necessary; prefer lightweight fixtures and isolated units.
+
+
+## UI Specific instructions 
+
+### React
+
+- Use styled component's theme prop to manage CSS colors and not CSS variables when in the context of a styled component or any react component using the styled component 
+- Styled Components are used as wrappers to define both self and children components style, tailwind classes are used specifically for layout based styles. 
+- Styled Component CSS might also change layout but tailwind classes shouldn't define colors. 
+
 ## Readability and Abstractions
 
 - Avoid abstractions unless the exact same code is being used in more than 3 places.