@jhumelsine.bsky.social
The bottom of this section contains a link to a Google NotebookLM that's been populated with all of my test blogs. You can interact with the content that way without having to read all of my content.
The link's a bit too long to copy-and-paste here.
The link's a bit too long to copy-and-paste here.
November 28, 2025 at 3:10 PM
The bottom of this section contains a link to a Google NotebookLM that's been populated with all of my test blogs. You can interact with the content that way without having to read all of my content.
The link's a bit too long to copy-and-paste here.
The link's a bit too long to copy-and-paste here.
Here's a Table of Contents of my complete Automated Test blog series: jhumelsine.github.io/table-of-con...
Table of Contents
A little bit of order to organize the chaos.
jhumelsine.github.io
November 28, 2025 at 3:08 PM
Here's a Table of Contents of my complete Automated Test blog series: jhumelsine.github.io/table-of-con...
Duh. I checked my Automated Testing series, and found this one too, which I think is more aligned with your original request: jhumelsine.github.io/2024/06/14/u...
Attributes of Effective Unit Tests
Unit Test properties that make them more useful than not
jhumelsine.github.io
November 28, 2025 at 3:07 PM
Duh. I checked my Automated Testing series, and found this one too, which I think is more aligned with your original request: jhumelsine.github.io/2024/06/14/u...
Already posted on X, but adding it here in case there's any further discussion.
Here's my own list in blog form. It probably repeats many elements that you've already found: jhumelsine.github.io/2024/08/30/t...
Here's my own list in blog form. It probably repeats many elements that you've already found: jhumelsine.github.io/2024/08/30/t...
Testing Benefits
Spoiler Alert – It’s not really about testing the code
jhumelsine.github.io
November 28, 2025 at 1:21 PM
Already posted on X, but adding it here in case there's any further discussion.
Here's my own list in blog form. It probably repeats many elements that you've already found: jhumelsine.github.io/2024/08/30/t...
Here's my own list in blog form. It probably repeats many elements that you've already found: jhumelsine.github.io/2024/08/30/t...
I always felt that 10,000 hours was necessary, but not sufficient.
I think many interpreted Gladwell's presentation as it being sufficient.
I think many interpreted Gladwell's presentation as it being sufficient.
November 26, 2025 at 1:56 PM
I always felt that 10,000 hours was necessary, but not sufficient.
I think many interpreted Gladwell's presentation as it being sufficient.
I think many interpreted Gladwell's presentation as it being sufficient.
Oops, should be: ... cells -> organelles -> bio-molecules ...
November 15, 2025 at 2:53 PM
Oops, should be: ... cells -> organelles -> bio-molecules ...
Consider biology, which is its own biotech stack.
Organisms -> systems -> organs -> cells -> bio-molecules -> ...
While scientists can understand concepts at each level, understanding each supporting level helps us understand the levels above it.
Organisms -> systems -> organs -> cells -> bio-molecules -> ...
While scientists can understand concepts at each level, understanding each supporting level helps us understand the levels above it.
November 15, 2025 at 2:51 PM
Consider biology, which is its own biotech stack.
Organisms -> systems -> organs -> cells -> bio-molecules -> ...
While scientists can understand concepts at each level, understanding each supporting level helps us understand the levels above it.
Organisms -> systems -> organs -> cells -> bio-molecules -> ...
While scientists can understand concepts at each level, understanding each supporting level helps us understand the levels above it.
However, when you find code that doesn't look correct, still document it with a test, but add SHOULD_IT to the end of the test name.
Then create a ticket highlighting the test for someone with more domain knowledge to evaluate.
Then create a ticket highlighting the test for someone with more domain knowledge to evaluate.
November 13, 2025 at 11:11 PM
However, when you find code that doesn't look correct, still document it with a test, but add SHOULD_IT to the end of the test name.
Then create a ticket highlighting the test for someone with more domain knowledge to evaluate.
Then create a ticket highlighting the test for someone with more domain knowledge to evaluate.
AI would basically be automated characterization tests, which don't address correctness or not.
I wrote about this to some degree in this section of my legacy code blog: jhumelsine.github.io/2025/03/24/l...
TL;DR - We can usually assume that legacy code is correct, since users confirm it.
...
I wrote about this to some degree in this section of my legacy code blog: jhumelsine.github.io/2025/03/24/l...
TL;DR - We can usually assume that legacy code is correct, since users confirm it.
...
Working Effectively with Legacy Code
… with all due respect to Michael Feathers in stealing his book title and a lot of his ideas for this blog
jhumelsine.github.io
November 13, 2025 at 11:11 PM
AI would basically be automated characterization tests, which don't address correctness or not.
I wrote about this to some degree in this section of my legacy code blog: jhumelsine.github.io/2025/03/24/l...
TL;DR - We can usually assume that legacy code is correct, since users confirm it.
...
I wrote about this to some degree in this section of my legacy code blog: jhumelsine.github.io/2025/03/24/l...
TL;DR - We can usually assume that legacy code is correct, since users confirm it.
...
I can see one possible application: Use AI tests to add coverage to legacy code that does not have tests.
AI tests would provide temporary coverage to refactor and reveal behavior and intent. Then replace AI tests with behavior inspired human written tests.
AI tests would provide temporary coverage to refactor and reveal behavior and intent. Then replace AI tests with behavior inspired human written tests.
November 13, 2025 at 1:34 PM
I can see one possible application: Use AI tests to add coverage to legacy code that does not have tests.
AI tests would provide temporary coverage to refactor and reveal behavior and intent. Then replace AI tests with behavior inspired human written tests.
AI tests would provide temporary coverage to refactor and reveal behavior and intent. Then replace AI tests with behavior inspired human written tests.
I've got three reasons:
1. Software practices are not presented by academia.
2. Prisoners Dilemma from Game Theory. Individuals are rewarded for closing tickets quickly rather than taking the time to invest in the codebase for the team.
3. It's too hard to break old habits.
1. Software practices are not presented by academia.
2. Prisoners Dilemma from Game Theory. Individuals are rewarded for closing tickets quickly rather than taking the time to invest in the codebase for the team.
3. It's too hard to break old habits.
October 28, 2025 at 8:58 PM
I've got three reasons:
1. Software practices are not presented by academia.
2. Prisoners Dilemma from Game Theory. Individuals are rewarded for closing tickets quickly rather than taking the time to invest in the codebase for the team.
3. It's too hard to break old habits.
1. Software practices are not presented by academia.
2. Prisoners Dilemma from Game Theory. Individuals are rewarded for closing tickets quickly rather than taking the time to invest in the codebase for the team.
3. It's too hard to break old habits.
I still like to rearrange the list so that they spell CLAMS or CALMS.
October 21, 2025 at 12:03 PM
I still like to rearrange the list so that they spell CLAMS or CALMS.
Here's the section of my Legacy Code blog entry that summarizes Characterization Testing and introduces the concept of AI Generation.
jhumelsine.github.io/2025/03/24/l...
jhumelsine.github.io/2025/03/24/l...
Working Effectively with Legacy Code
… with all due respect to Michael Feathers in stealing his book title and a lot of his ideas for this blog
jhumelsine.github.io
October 20, 2025 at 2:37 PM
Here's the section of my Legacy Code blog entry that summarizes Characterization Testing and introduces the concept of AI Generation.
jhumelsine.github.io/2025/03/24/l...
jhumelsine.github.io/2025/03/24/l...
However, Characterization Tests aren't the most fun to right, and they tend to be nasty, since the Legacy Code is probably nasty too.
If we trust that the legacy code is correct via user confirmation, then I think we can use AI to generate temporary Characterization Tests.
...
If we trust that the legacy code is correct via user confirmation, then I think we can use AI to generate temporary Characterization Tests.
...
October 20, 2025 at 2:37 PM
However, Characterization Tests aren't the most fun to right, and they tend to be nasty, since the Legacy Code is probably nasty too.
If we trust that the legacy code is correct via user confirmation, then I think we can use AI to generate temporary Characterization Tests.
...
If we trust that the legacy code is correct via user confirmation, then I think we can use AI to generate temporary Characterization Tests.
...
Characterization Tests provide safety scaffolding but tend to be implementation specific and brittle. CTs provide temporary safety to refactor legacy code hoping intent will emerge. Then replace CTs with behavior based tests from revealed intent.
...
jhumelsine.github.io/2025/03/24/l...
...
jhumelsine.github.io/2025/03/24/l...
Working Effectively with Legacy Code
… with all due respect to Michael Feathers in stealing his book title and a lot of his ideas for this blog
jhumelsine.github.io
October 20, 2025 at 2:36 PM
Characterization Tests provide safety scaffolding but tend to be implementation specific and brittle. CTs provide temporary safety to refactor legacy code hoping intent will emerge. Then replace CTs with behavior based tests from revealed intent.
...
jhumelsine.github.io/2025/03/24/l...
...
jhumelsine.github.io/2025/03/24/l...
I agree that I don't think that in general we should use AI to generate test cases. However, I see one possible exception with working legacy code, which is tested indirectly via our users.
This means that most legacy code "tends" to work even if we don't understand it.
...
This means that most legacy code "tends" to work even if we don't understand it.
...
October 20, 2025 at 2:36 PM
I agree that I don't think that in general we should use AI to generate test cases. However, I see one possible exception with working legacy code, which is tested indirectly via our users.
This means that most legacy code "tends" to work even if we don't understand it.
...
This means that most legacy code "tends" to work even if we don't understand it.
...
I agree. Tech Debt's original meaning has been usurped possibly forever. That's probably because there's so much Cruft when compared to the amount of OG Tech Debt.
October 13, 2025 at 8:01 PM
I agree. Tech Debt's original meaning has been usurped possibly forever. That's probably because there's so much Cruft when compared to the amount of OG Tech Debt.
I also feel that cruft is the unintended consequences of a lot of incentives. Not enough room for details here, but it's similar to the Tragedy of the Commons and the Prisoners Dilemma.
October 13, 2025 at 7:39 PM
I also feel that cruft is the unintended consequences of a lot of incentives. Not enough room for details here, but it's similar to the Tragedy of the Commons and the Prisoners Dilemma.
I now try to use "Technical Debt" in Ward Cunningham's original intent and "Cruft" for the short cuts that accumulate and eventually gum up the works in the implementation.
Tech Debt makes more sense as a term when consider with Cunningham's original intent too.
Tech Debt makes more sense as a term when consider with Cunningham's original intent too.
October 13, 2025 at 7:35 PM
I now try to use "Technical Debt" in Ward Cunningham's original intent and "Cruft" for the short cuts that accumulate and eventually gum up the works in the implementation.
Tech Debt makes more sense as a term when consider with Cunningham's original intent too.
Tech Debt makes more sense as a term when consider with Cunningham's original intent too.
Thanks for sharing. I've added it to the list of references in jhumelsine.github.io/2025/03/24/l...
Working Effectively with Legacy Code
… with all due respect to Michael Feathers in stealing his book title and a lot of his ideas for this blog
jhumelsine.github.io
October 7, 2025 at 4:51 PM
Thanks for sharing. I've added it to the list of references in jhumelsine.github.io/2025/03/24/l...
I reference the song "Que Sera, Sera" when it comes to YAGNI. "Whatever will be, will be. The future's not ours to see."
While we can't predict the future, it is coming.
Therefore, we should design so that we're flexible enough to accommodate whatever will be coming.
While we can't predict the future, it is coming.
Therefore, we should design so that we're flexible enough to accommodate whatever will be coming.
October 7, 2025 at 1:25 PM
I reference the song "Que Sera, Sera" when it comes to YAGNI. "Whatever will be, will be. The future's not ours to see."
While we can't predict the future, it is coming.
Therefore, we should design so that we're flexible enough to accommodate whatever will be coming.
While we can't predict the future, it is coming.
Therefore, we should design so that we're flexible enough to accommodate whatever will be coming.