lancerkind

The interview series starts at episode 252 and is ongoing.

Interview of Indian software engineer made famous for discovering lander wreckage on moon. Interviewed by NYT and others. Episodes 251, 252, and ongoing.

Macro tests, micro tests, subcutaneous tests. And CI.

clickable link to the podcast interview: https://lancerkind.com/series/scifi-thoughts/

episode 175 Real Life Discoverer of Lost Lunar Lander—Shanmuga

episode 176 Software Engineer gets the Keys to the City and State

episode 177 How Discovering Moon Debris made a Software Engineer Famous

Drawful 2 is great for zoom happy hours. https://www.jackboxgames.com/were-giving-away-drawful-2-for-...

And it's free for a few weeks.

This game requires collaboration and leverages the "doer" and "thinker" model. The negative is that the players will all need to buy a low-cost license. https://apps.apple.com/app/keep-talking-nobody-explodes/id14...

SciFi Thoughts interview https://lancerkind.com/podcast/061-orphan-black-audio-drama/

Link to show archive: https://agilenoir.biz/series/agile-thoughts/

About Spikes: They are a tool to be employed when no one on the team has confidence in how to solve a technical problem. Spikes are used to deliver learning through doing. They are a Plan B. Used when we can't do Plan A--write the tests and the code with TDD. Because it takes longer to write tests later, the Spike is a simple implementation to learn something. Once the learning has happened, then you go into the code and use TDD to develop the product code. The spike code is never meant to be product code.

Don't you think it's a misuse if ALL of your development is using spikes?

Don't you think that this use of Spikes is a crutch to avoid something you are unmotivated do and haven't invested time to learn?

So "thinking test first" means you've reached proficiency. How would you observe "thinking test first" behavior?

Nice points here.

I'll have to do a show on "spike and stabilize." This strategy of "late" refactoring and micro testing is something we are forced to do when encountering untested legacy code. So this as part of the "tool kit" to be a master and difficult for someone who is proficient.

My perception is that Spike and Stabilize, always takes longer than TDD because:

  1) I have to spend time "re-discovering" what the code is supposed to do in order to write the test.  
  2) If I need to use the debugger or print statements to learn what the code is doing, 
     these temporary diagnostics aren't automatable and the value achieved
     can't be checked into source code.  
  3) I have to work harder at bad design decisions that occur when not thinking about unit testing. 
  4) I find APIs aren't as intuitively crafted because TDD forces you to define your interface 
  to get started (a simple version which evolves as needed) rather than 
  the steps of: "write code, get it working, go back and refactor and test"
  5) The costs increase with Spike and Stabilize with the time delta between
  the moment the code is written to the moment tests are added.  
  6) Plus Spike and Stabilizes allows people to be pressured into doing the
  wrong thing: ship it now, worry about test automation later.  
  If you're disciplined, this won't matter because you can simply say no.
  If you're not, test debt increases.  TDD removes this possible risk.

Thank you for the suggestion on explicitly adding the TDD "mantra" of red/green/refactor. In episode 22, TDD with a Stack Overflow Master Developer, it explores TDD versus Spike and Stabilize Later in a dramatic presentation: https://agilenoir.biz/podcast/022-tdd-with-a-stack-overflow-... This story of a developer going through the challenges of getting his team to do TDD starts with episode 14: https://agilenoir.biz/series/agile-thoughts/

Thank you for the name, "spike and stabilize." It sounds better than "Test Later Strategy" but I fear it obscures the risky and uncertain future.

It’s a container, which has its own networking and process containment. (You can list the processes running and you will only see your own process running in the container.) You get to build and configure your container using the command line. And contain those steps as a definition file is reproducibility and “infrastructure as code” is handled.

And these containers can run on a bare metal Linux box, so unlike VMs Docker removes abstractions and overhead.

Docker simplifies software development and deployment so you don’t need a lot of additional configuration tools for infrastructure as code.

Test Automation Strategy Series https://agilenoir.biz/series/agile-thoughts/

001 Build a solid pyramid 002 Microtests at the base of the pyramid 003 Macrotests at the top of the pyramid 004 The Pyramid's secret floor 005 Subcutaneous Tests 006 Riddles from the Sphinx and Answers within the Pyramid 007 Size Matters 008 The Conductor: Continuous Integration

The Test Driven Development series continues. Visit and listen to these insightful, easy to understand, and entertaining episodes about TDD. At Agile Thoughts, we work hard to be Portlandia friendly. ;-)

https://agilenoir.biz/series/agile-thoughts/

009 Introducing the Test Driven Development series 010 Agile and TDD Neglect 011 The Old Way isn't Sustainable 012 An Example of doing TDD 013 Developer Intent and the Bible 014 Why Devs don’t TDD 015 The TDD FUD Spreader 016 Driving under the Influence of FUD 017 The Architect Disses TDD 018 TDD gets no Love from the PO 019 A QA Professional Questions Micro Tests and TDD 020 TDD Undoer

The static typing makes mocking harder (Java, C#). Working in Javascript makes mocking so easy you don’t need a mocking framework. TDD is an awesome practice in all languages, strongly types or not.

I played a bit with mock driven development (I think this is the same as mockist). I so for haven’t found that valuable other than as a kata for learning a new mocking framework.

@walligaotr Have you found mockist useful?

Agreed. Well said and good points.

Agreed: * Step 1) (macro) ATDD one or more acceptance criteria * Step 2) (micro) TDD your code to get a macro test to pass.

Nice! That’s is the best workflow for me too. Your basically working from big picture downward or said another way: outside in.

To do so otherwise creates more risk. I feel the bottom up approach leaves me exposed to discover bad news later in the game and I have to go back and refactor or toss a bunch of code.

Lol. Absitinence only sex Ed has nothing to do with TDD. Nor is it fundamentalism. It’s a waste of time to ponder as no real conclusions can be made from slapping the fundamentalism label on TDD. Better to just have an open mind and give it a go. And pay attention to the real benefits than to poison your mind against trying something that could help you deliver more features.

Nice idea to use defect injection to test the automated tests.

There are test frameworks for every tier of any application on any platform. People are getting it done.

Testing pixel presentation is a problem. Today, Automated macro tests can’t describe in a program how the UI should look before the UI is built. The UI is simply too dynamic and subject to the whims of fashion. But writing tests first for the UI and smoke testing that the UI elements are there and basically function is doable.

Most devs struggle keeping their micro testable code seprate from presentation code. TDD is a great way to incur this requirement. Otherwise it needs to be tested in a slow macro UI test. If you’re not familiar with the three tiers of the Test Automation pyramid, give Agile Thoughts episodes 1 through 4 a listen. It takes you through each stage of the pyramid and describes how macro (cutaneous and subcutaneous) and micro complement each other. https://agilenoir.biz/series/agile-thoughts/

It’s best to have both micro tests (TDD) and macro tests (Acceptance Tests, which if you write acceptance tests first, is referred to as ATDD). TDD refers to micro tests. ATDD is what you should say to communicate clearly what your doing. Saying TDD when you mean ATDD will cause confusion with those who have mature test automation practices. Macro versus micro are important distinctions as they need to be managed differently. Mix those two test inventories together actually causes damage as all your test infrastructure will be slow rather than having a micro test suite that’s faster and run more frequently. Check out Agile Thoughts episodes 1 through 8 for background on this. https://agilenoir.biz/series/agile-thoughts/

:-)

I actually enjoy writing well crafted code that does test and production functionality. Still, I admire your spirit. Just don’t join my team. ;-)

None of those tests will silently fail. That’s their point for existing. They complain when the code stops operating as the developer designed it to work.

Integration testing is valuable. It just isn’t scalable to the whole code base (because, as you said, it’s slow), that’s why macro tests should be targeted to the parts that can’t be micro tested (10-15%), leaving the bulk of the code to be tested with blazing fast micro tests. Agile Thoughts podcast goes over this during a series on the Testing Pramid, episodes 1 through 8. https://agilenoir.biz/series/agile-thoughts/

It’s a false equivalence to equate TDD to religions as the effects are observable and measurable with TDD. In contrast, none of my loved ones have contacted me from the afterlife nor has any diety ever responded to my exhortations.

Brilliantly said!