Jure Leskovec was my Professor at Stanford a few years back, cool to see he's behind this.

He seemed like a good guy and got the sense that he was destined to do something big

Vid is a good friend of mine and he's wicked smart and also a very solid guy I adore.

I'm also guessing at some point he will probably read this comment, so hey Vid! See you at the next VRSA meetup!

Wickedly smart team indeed!

I remember Kumo was focusing on GNN when it was founded (Jure's strength back then). Looks like they are pivoting or have pivoted.

I thought it was interesting - not revolutionary but updated my thinking a bit.

Writing a failing test that reproduces a bug is something I learned pretty early on.

But I never consciously thought about and approached the test as a way to debug. I thought about it more of a TDD way - first write tests, then go off and debug/code until the test is green. Also practically, let's fill the gap in coverage and make sure this thing never happens again, especially if I had to deal with it on the weekend.

What was interesting to me about this was actively approaching the test as a way of debugging, designing it to give you useful information and using the test in conjunction with debugger

> What was interesting to me about this was actively approaching the test as a way of debugging, designing it to give you useful information and using the test in conjunction with debugger

I'm curious, if you're using TDD weren't you already doing this? A test that doesn't give you useful information is not a useful test.

I think the distinction is that if you write a test that reproduces the bug, that's a binary signal and doesn't by itself tell you anything about why the bug is happening.

In contrast, if you write tests that rule out particular causes of a bug you're incrementally narrowing down the potential causes of the bug. So each test gives you information that helps you solve the bug, without directly stepping through the code.

Unfortunately, I don't think the post is a great primer on the subject.

> Unfortunately, I don't think the post is a great primer on the subject.

It isn't, nor is it intended to be. It's an advert:

>> While mastering unit tests as debugging tools takes practice, AI-powered solutions like Qodo can significantly accelerate this journey. Qodo’s contextual understanding of your Java codebase helps it automatically generate tests that target potential logic vulnerabilities.

> then go off and debug/code until

Yes, this is a missed opportunity! Well said. I try to write tests in place of print statements or debuggers, using assertions like xray glasses. Fun times!

I'm happy for you that you learned something and sad for me because you made me feel old and stupid.

I tend to forget that people don't know stuff I learned decades ago and consider them as general knowledge.

Before TDD became what it was, we used to create specific files for specific bug cases, or even get the files from the users themselves.

> I tend to forget that people don't know stuff I learned decades ago and consider them as general knowledge.

While all of us who are lucky to be around long enough meet the problem of general knowledge changing under our feet, it's hard for me to imagine how saying this to someone can be a productive contribution to the conversation. What can it accomplish other than making someone feel worse for not knowing something that you consider general knowledge?

I don't think anyone should feel bad for not knowing something.

My "general" knowledge is built on my experience.

The first comment before OP answer's was kinda condescending about the article and I felt the same way when reading it but then op's comment made me realise I was in the wrong because I forgot that my "general" knowledge is not general at all.

OP had to defend why he posted it. I wanted to tell OP that it was a good idea to post it, not for the article content, but for my teaching moment.