I've never done formal testing (still a student), but I've always, always tested as I went and before any "version" updates (or what would be the equivalent of if I was versioning with numbers, etc). Maybe it's because I learn best by breaking things or because of my math background where I helped too many students figure out why their proofs weren't valid (spoiler: using "2" as one of your test numbers is almost always the wrong choice because it does weird stuff) or because I always want to figure out the holes in something, but I've always just sort of done it reflexively.
I'm working on a side project now and as I go I either make notes of things to check later or I go "Hmmm, I wonder if ABC breaks it... yup, yup it does. OK, is that a case I didn't account for and should have in the code, or is there an error somewhere?" and then I dig around and adjust.
I've never used tools to do it, though. Maybe that'll be one of my winter break detours...!
Thanks @alephnaught2tog
for your reply! I'm also still a student, so in university, we learned formal testing in theory, but in our study projects, we never really applied it, because time was always very limited and the whole application was just a proof-of-concept, so nobody cared 😇
In my side projects I tested my apps just by trying them out and see if they crashed. When they crashed, I tried to fix them immediately, but if this took too much time I often let my future self a// TODO: note to come back later. But I think after I've seen formal testing can be so easy, it will reduce my time to manually testing things.
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 never done formal testing (still a student), but I've always, always tested as I went and before any "version" updates (or what would be the equivalent of if I was versioning with numbers, etc). Maybe it's because I learn best by breaking things or because of my math background where I helped too many students figure out why their proofs weren't valid (spoiler: using "2" as one of your test numbers is almost always the wrong choice because it does weird stuff) or because I always want to figure out the holes in something, but I've always just sort of done it reflexively.
I'm working on a side project now and as I go I either make notes of things to check later or I go "Hmmm, I wonder if ABC breaks it... yup, yup it does. OK, is that a case I didn't account for and should have in the code, or is there an error somewhere?" and then I dig around and adjust.
I've never used tools to do it, though. Maybe that'll be one of my winter break detours...!
Thanks @alephnaught2tog for your reply! I'm also still a student, so in university, we learned formal testing in theory, but in our study projects, we never really applied it, because time was always very limited and the whole application was just a proof-of-concept, so nobody cared 😇
In my side projects I tested my apps just by trying them out and see if they crashed. When they crashed, I tried to fix them immediately, but if this took too much time I often let my future self a
// TODO:note to come back later. But I think after I've seen formal testing can be so easy, it will reduce my time to manually testing things.