But now you have the tests to be able to refactor the implementation and improve it.
I’ve been in too many projects where devs almost never write tests. They cut corners by neither writing tests nor documentation because of time pressure. Then the code breaks in production with simple edge cases like NullPointerException and they need to fix it, so they don’t have time to write unit tests for the next feature. And it’s definitely harder to write tests after you implemented something.
Can you link to an implementation you would consider great?
I would just like to compare them. I too find Uncle Bobs “clean code” book very much overrated.
My understanding of the “design” aspect of TDD is, that you start from client code and create the code that conforms to your tests. Too often I worked in a team with other developers and I wanted to use what they wrote, and they somehow coded what was part of the spec, but it was unusable from my code. Only because I was able to change their code (most often the public API) I was able to use it.
It’s similar in Java, where people often only know about public and private, and forget about package scoped functions. You can use these to test utility functions etc.
The post is weird, I agree with almost everything in the first half and disagreed with most of the second part.
What makes TDD hard for integration testing is that there are no simple readymade tools similar to XUnit frameworks and people need to build their own tools and make them fast.
I think cooking is very similar to programming. You need to basically do it with your hands otherwise you won’t “get” it. The ingredients are one thing. The chemistry behind it is another thing. Both probably easily to teach through a book. Knowing how to hold the knife and how to dice onions fast is something you can only learn by practicing. Even better someone showing it first (eg through a video), but it won’t work without practice.
I think one important part of Gentrification means there are people with more money moving into a neighbourhood. The real estate agents just showed the building to them on the quiet day and they bought their piece of it, believing it's like this all day every day. And when they move in, they realise the quietness was rather the exception than the rule. If they were from the area before, they would have known. But because they payed this amount of money, they think they bought the right to a have the quietness they were sold on.
I've seen similar things in Berlin in the 90s and early 2000s when West-Germans, mostly from Swabia moved in. They were sold apartments next to Youth clubs and the new neighbours didn't like that they had loud music on Friday and Saturday nights. But this was Berlin, this was what it was famous for. But whatever, a lot of the clubs had to shut down.
I think a good strategy for Microsoft would be to reuse as much as possible CI/CD code from github in Azure devops. Azure devops probably doesn’t need to be as flexible as long as it is robust and just works. Github will probably be the place where experiments can happen.
I'm looking for something I could put between two docker images to test for problems that arise from slow API connections.
I have go code (open source, but not written by me), I suspect to have timeouts in certain situations and I would like change the code to be failure tolerant.