Looking forward to our conference! Indeed, we begin with the unfortunate reality of software development industry in 2024... and I do hope that as we learn from our speakers, that we'll be able to change the software development industry!
Thanks for sharing this post Valentina, and best wishes for your incoming talk.
About today's post, I see 2 points.
1. For cases of brand new services. It's zero effort having the right tests. When you start from the scratch you have the beloved "green field" and starting with TDD will help you have a clear set of acceptance tests that will tell you what your service have to do. Doing tests before you can even ask later to Copilot to write the actual code!? (did you tried that?). Anything else, IMHO, are just excuses.
2. For cases of legacy code. This is more tricky. I my experience, what I do is going to the specs of the application (what the service should do) and start implementing my tests from there. When I find some code that is following the right pattern: refactor and move forward!
1. Yes, in case of Greenfield projects I'd definitely recommend ATDD (and also TDD at Component Level). As far as TDD at the Unit Level, maybe not yet, if the domain isn't too complex (I'm saying this from startup perspective). I think humans should write tests, and then Copilot can be used for making the test pass, and sometimes (maybe yes maybe not) for refactoring.
2. In case of Legacy, often there aren't any specs, so I'd start off with existing Manual QA Tests (generally documented someone, or if not I'd ask for them to be documented), converting those into E2E Tests, then Acceptance Tests, etc...
The tools have advanced, while the technical practices have stayed the same.
Yes, that's a big problem in the software industry, too much focus on advancing tools, whilst technical practices are gathering dust.
"The mainstream development approach still remains the Big Ball of Mud."
Isn't that the truth! In many ways we've gone backwards from where we were 25 years ago :(
It is very unfortunate. In other industries, quality is much more regulated, but in software development it is optional.
"In many ways we've gone backwards from where we were 25 years ago" -> I'd like to hear more on that topic.
We elegantly begin the conference with a banger session, can't wait!
Looking forward to our conference! Indeed, we begin with the unfortunate reality of software development industry in 2024... and I do hope that as we learn from our speakers, that we'll be able to change the software development industry!
Thanks for sharing this post Valentina, and best wishes for your incoming talk.
About today's post, I see 2 points.
1. For cases of brand new services. It's zero effort having the right tests. When you start from the scratch you have the beloved "green field" and starting with TDD will help you have a clear set of acceptance tests that will tell you what your service have to do. Doing tests before you can even ask later to Copilot to write the actual code!? (did you tried that?). Anything else, IMHO, are just excuses.
2. For cases of legacy code. This is more tricky. I my experience, what I do is going to the specs of the application (what the service should do) and start implementing my tests from there. When I find some code that is following the right pattern: refactor and move forward!
Thanks for your support.
1. Yes, in case of Greenfield projects I'd definitely recommend ATDD (and also TDD at Component Level). As far as TDD at the Unit Level, maybe not yet, if the domain isn't too complex (I'm saying this from startup perspective). I think humans should write tests, and then Copilot can be used for making the test pass, and sometimes (maybe yes maybe not) for refactoring.
2. In case of Legacy, often there aren't any specs, so I'd start off with existing Manual QA Tests (generally documented someone, or if not I'd ask for them to be documented), converting those into E2E Tests, then Acceptance Tests, etc...
"We’re fire-fighting, yet talking about AI?!"
Right? I say the same every time the printer does not work 😅
Yes, it's like trying to solve equations in algebra, yet not knowing how do basic math operations.