I've been running Tabnine Pro across my team's IDEs for about 18 months now, primarily for its on-prem deployment options and the security/compliance benefits that brings. Overall, it's been a net positive for our production code, especially with boilerplate, common API patterns, and documentation. However, I've found myself consistently—and now instructing my team to do the same—disabling it entirely when working within test directories.
The core issue is that Tabnine's suggestions, which are trained on vast corporates of existing code, tend to promote the most common, and often the most trivial, patterns. This is actively detrimental to effective testing. Let me illustrate with a concrete example.
When I'm writing a unit test, I'm not looking for the most common assertion. I'm looking for the *correct* and *specific* assertion for the edge case I'm probing. If I start typing `assertTh`, I don't want Tabnine to automatically complete to `assertThat(someCommonVariable).isNotNull()`. That's a useless, low-signal test. I want to deliberately write `assertThrows(SomeSpecificException.class, () -> { ... })`. The cognitive interruption of dismissing the overly-helpful, generic suggestion breaks my flow and, worse, can lead to lazy test patterns through mere acceptance.
Furthermore, the nature of test setup is different. Test data factories, mocking behavior, and complex orchestration for integration tests are highly contextual to our codebase. Tabnine's generalized suggestions here are either irrelevant or misleading. For instance, in a Jest test:
```javascript
jest.mock('../someModule');
// Tabnine might suggest a common, generic mock implementation here,
// but my mock needs to return a very specific error state for this test case.
// The suggestion is noise.
```
My current workflow, which I've codified in our team's dev environment guide, involves using IDE-specific settings to exclude test file paths. In VS Code, for instance, it's straightforward to add a `tabnine.ignoreFiles` pattern.
**My configuration snippet:**
```json
{
"tabnine.ignoreFiles": [
"**/__tests__/**",
"**/*.test.*",
"**/*.spec.*",
"**/test/**",
"**/Test/**"
]
}
```
This gives us the best of both worlds: AI-assisted development in the main source, where common patterns are valuable, and unimpeded, intentional craftsmanship in the test suite. I'm curious if others in architect or team lead roles have arrived at a similar practice. Have you found alternative strategies, like using more granular prompt contexts or different rules for integration vs. unit tests? Or is disabling it for tests the pragmatic consensus?
Mike