Add unit tests for TargetInsertStatement bind input validation and bind-index ordering

[vasiliy-mikhailov]

Results

Metric	Before	After
Mutation score	47/72 killed (65%)	52/72 killed (72%)
Line coverage	136/182 (75%)	138/182 (76%)

Scope: tests only, measured with PIT 1.18.0 on JDK 17. targetClasses = com.datastax.cdm.cql.statement.TargetInsertStatement, com.datastax.cdm.cql.statement.TargetUpsertStatement; targetTests = com.datastax.cdm.cql.statement.TargetInsertStatementTest. Each run did a forced clean test-class recompile (clean test-compile in the same Maven invocation as the mutationCoverage goal) so the before/after numbers reflect the actual test change: +5 mutants killed (65% -> 72%), test strength 73% -> 81%.

What this adds

Adds 9 unit tests to TargetInsertStatementTest covering com.datastax.cdm.cql.statement.TargetInsertStatement.bind() and the shared input validation it inherits from TargetUpsertStatement:

• TTL/writetime input validation: bind() throws with the expected message when TTL or writetime columns are enabled but no value is supplied, before any value is bound.
• Sequential bind indices verified via ArgumentCaptor for all target columns.
• Constant-column skipping: only non-constant columns are bound, at sequential indices.
• Explode-map binding sets every target column at sequential indices.
• TTL(Integer) and writetime(Long) placement and types at the correct trailing indices.
• Combined TTL + writetime binding order and types.
• Bind-time conversion-failure wrapping (Error trying to bind value).

Tests only, no production changes. JDK 17.

Scope

Tests only. No production code is modified; the change adds test methods to src/test/java/com/datastax/cdm/cql/statement/TargetInsertStatementTest.java.

Disclosure

This PR was generated with an AI-assisted pipeline built around mutation testing (PIT). The pipeline mutates the target class (flipping conditions and changing boundary/edge cases) and runs the existing tests against each mutant; where a mutant survives (the existing tests do not catch that edge case), it writes a focused test for that case and reruns PIT to confirm the new test actually kills that specific mutant.

[msmygit]

Thank you @vasiliy-mikhailov for your contribution! May I ask you which company do you work for and curious why you've begin improvising the unit testing side of CDM? What's the end goal? This is super great and I was just curious on the goals.

[msmygit]

lgtm 👍🏼

[vasiliy-mikhailov]

Hi @msmygit — thank you, that really means a lot!

Honestly, there's no company behind this. I work on it in my free time. I love open source, and I'm genuinely fascinated by what AI can do right now — and this is exactly where the two meet for me. I've been exploring how an AI-assisted pipeline built around mutation testing (PIT) can strengthen the test suites of projects I admire: it finds the edge cases the existing tests miss and writes focused tests that actually catch them.

CDM was a natural fit — a real, well-maintained project where stronger tests have obvious value. The end goal is simple: to show that, at this particular moment, AI can genuinely help fuel open-source unit testing, and to give something back rather than just tinker in isolation. Everything stays tests-only and openly disclosed as AI-assisted, so you and the team keep full control over what lands.

Thanks again for taking the time to ask — happy to go deeper on any of it.

[msmygit]

Thank you @vasiliy-mikhailov! Also, have you considered increasing the COVEREDRATIO (for COMPLEXITY & INSTRUCTION) and decreasing the MISSEDCOUNT to see if there is an improvement experienced with your additional tests coverage?

[vasiliy-mikhailov]

Done — I've gone ahead and tightened them in this PR (latest commit). With the added tests, the build now reaches INSTRUCTION 54.1%, COMPLEXITY 43.7%, and 1475 missed lines, so I raised the check to:

• COMPLEXITY COVEREDRATIO 0.42 → 0.43
• INSTRUCTION COVEREDRATIO 53% → 53.5%
• LINE MISSEDCOUNT 1490 → 1480

All pass locally (mvn clean test green with the check enforcing), and I kept a small margin so routine changes won't trip the gate. Happy to ratchet harder if you'd prefer.

There's also plenty more coverage to be had — CqlTable, CqlConversion, and PKFactory are the biggest gaps — if you're open to follow-up test PRs.

[Packsolite]

May I ask you which company do you work for and curious why you've begin improvising the unit testing side of CDM

It's an AI bot selecting random java repositories and creates a PR with unit tests, possibly to farm some github stats.
Over at BungeeCord it gave absurd answers to simple domain-specific questions when asked.

[vasiliy-mikhailov]

Are you the owner of the @vasiliy-mikhailov AI bot? Which company do you work for?

No, i just stumbled across it because it opened a useless PR in the BungeeCord repository. When maintainers confronted him, the bot hallucinated unrelated information. I don't work for any company, I just got curious and thought I'd leave a comment on "who" you are dealing with. Feel free to ignore it and move on :)

Guys, I'm not a bot. Yes, my pipeline produced a bad test for BungeeCord, which I’ve already fixed by hand, and I've upgraded the pipeline since then. I'm really sorry for the noise and any inconvenience caused. I genuinely believe that AI is the future and that it can help make open-source software even more robust. I don't just pick repositories at random; I look for projects that already have great unit tests and try to help strengthen them by improving their mutation scores. I completely understand if you're skeptical, but I’d be truly happy to collaborate whenever you feel ready.