I've been a professional developer for 23 years and have never used automated testing in any projects. I've had a go at working in this way and just find that writing the tests slows me down and ruins my coding flow. For me, I feel it adds an unnecessary overhead to development
Reads pretty much the same as most articles promoting TDD. To me, it doesn't really reflect the reality of development (at least the way I do it). While I'm coding, ideas come to me thick and fast and I will often do a total u-turn on how a function is implemented or have a complete change of heart on how a large problem should be solved. The whole process is very fluid and organic - taking place in one place - without jumping 'out of the code'. Having to keep leaping out of that flow really does not work for me and I feel ends up with an inferior end result that took longer to produce.
I'm not sure if the way I learned to code has anything to do with my methods - quite possibly I guess as I am totally self taught - from the age of 7. I have no formal qualifications or training as a programmer - just 35 years of experience (about 23 professionally)
To add to this healthy discussion, this 3 part hangout series video is pretty good as well.
Lots of pros & cons perspective from 3 of the top many names in the software industry today.
Hey Jon! I know in Software engineering we usually accept a lot of things as "revealed truth" and maybe never question them as long as they serve our purpose. I have found testing things thorough automation to be a revealed truth because it helped me work in what I feel is a better way.
And so, I'm curious about some aspects of your workflow, if you don't mind:
First of all, what sort of technology do you work with (I mean languages, fwks, etc)?
Do you work in a team/s? Or have you?
How do you make sure everything works after new features or refactors (big and small)?
Do you use/need continuous deployment or integration? If so, how do you ensure that newly deployed/merged code is not breaking any of the old things?
do any of these things, if not done by tests, take up a considerable amount of Time?
Just in case: I'm not trying to find a way to prove I'm right, I'm just curious about your context and workflow.
Through most of my web development experience (I've built desktop apps for windows too - Visual Basic back in the day) I have worked with PHP, JS, HTML CSS. In recent years I have also worked with node.js and Ruby. Current projects I am involved with utilise PHP, Ruby, and JS.
Working in teams:
I have worked solo and as part of teams large and small. Everything from building my own frameworks from scratch and using them for freelance work; to planning and architecting a large project, hiring my own team, running the project as a lead developer; and working in teams responsible for smaller parts of very large websites. In recent years I have been in larger companies, and have responsibility for a number of smaller projects which I work on mostly solo.
How to make sure everything works?
Continuously (manually) testing my work whilst in development, being sure to test all areas that the changed code affects. I'm usually fairly confident that a refactored function will work before I run it (I kind of run code in my head - others do this too, surely?) and usually I find the main reason it doesn't is simply typos. Admittedly the languages I work with allow for very quick changes and re-tests (i.e. no compilation)
Using CI:
Yes, at the last few jobs I have had we use CI. Everything is tested again (manually) in a staging environment before going live (a number of people test at this point, and only when all are happy is it pushed to production). I should point out that this is only the projects I have been involved with. Other projects within the organisations have had automated testing, but not all
Testing taking a considerable amount of time:
During my development, I would say no, but again as I pointed out - I work with technologies that lend themselves well to a fast change/test process. As for others testing at the staging environment - they are essentially just checking from an end user point of view making sure all functionality is working. I couldn't speak for them as to whether testing slows them down.
Hi Jon, I totally understand your comment. I've been a developer for more than 30 years; now It's just 10 years I'm into testing.
It was so difficult at first, I could see only a black mess without meaning and without form. But I was stubborn and went to a course to learn in practice.
Now I don't use tests on 100% of the project, but I know that some parts are easier to develop and maintain with tests than without.
To get there I needed a very big mental shift.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've been a professional developer for 23 years and have never used automated testing in any projects. I've had a go at working in this way and just find that writing the tests slows me down and ruins my coding flow. For me, I feel it adds an unnecessary overhead to development
Have a read of this
geepawhill.org/tdd-and-the-lump-of...
What do you think?
Reads pretty much the same as most articles promoting TDD. To me, it doesn't really reflect the reality of development (at least the way I do it). While I'm coding, ideas come to me thick and fast and I will often do a total u-turn on how a function is implemented or have a complete change of heart on how a large problem should be solved. The whole process is very fluid and organic - taking place in one place - without jumping 'out of the code'. Having to keep leaping out of that flow really does not work for me and I feel ends up with an inferior end result that took longer to produce.
I'm not sure if the way I learned to code has anything to do with my methods - quite possibly I guess as I am totally self taught - from the age of 7. I have no formal qualifications or training as a programmer - just 35 years of experience (about 23 professionally)
To add to this healthy discussion, this 3 part hangout series video is pretty good as well.
Lots of pros & cons perspective from 3 of the top many names in the software industry today.
youtube.com/watch?v=z9quxZsLcfo
Hey Jon! I know in Software engineering we usually accept a lot of things as "revealed truth" and maybe never question them as long as they serve our purpose. I have found testing things thorough automation to be a revealed truth because it helped me work in what I feel is a better way.
And so, I'm curious about some aspects of your workflow, if you don't mind:
Just in case: I'm not trying to find a way to prove I'm right, I'm just curious about your context and workflow.
Technologies I work with:
Working in teams:
How to make sure everything works?
Using CI:
Testing taking a considerable amount of time:
Hi Jon, I totally understand your comment. I've been a developer for more than 30 years; now It's just 10 years I'm into testing.
It was so difficult at first, I could see only a black mess without meaning and without form. But I was stubborn and went to a course to learn in practice.
Now I don't use tests on 100% of the project, but I know that some parts are easier to develop and maintain with tests than without.
To get there I needed a very big mental shift.