Been there, done that, would not recommend
-
Its definitely a bad idea writing new code that builds up on your old code, that has not been tested properly, because you quickly have to start debugging multiple layer is code at once.
-
Its definitely a bad idea writing new code that builds up on your old code, that has not been tested properly, because you quickly have to start debugging multiple layer is code at once.
Honestly this is the reason TDD is most important for personal projects.
If it's your job, the code isn't getting merged without decent tests. Yes you should probably write them first so you think about your implementation properly, but let's face it, many tests are written after in practice.
If it's something written in your free time, you're just not writing those tests most of the time if you didn't write them up front.
-
Honestly this is the reason TDD is most important for personal projects.
If it's your job, the code isn't getting merged without decent tests. Yes you should probably write them first so you think about your implementation properly, but let's face it, many tests are written after in practice.
If it's something written in your free time, you're just not writing those tests most of the time if you didn't write them up front.
Writing the tests first, or at least in tandem with your code, is the only way to fly. It's like publishing a proof along with your code.
it sounds trite: make the tests fit the code. Yes, it's a little more work to accomplish. The key here is that refactors of any scale become trivial to implement when you have unit-test coverage greater than 80%. This lets you extend your code with ease since that usually requires some refactor on some level.
-
Honestly this is the reason TDD is most important for personal projects.
If it's your job, the code isn't getting merged without decent tests. Yes you should probably write them first so you think about your implementation properly, but let's face it, many tests are written after in practice.
If it's something written in your free time, you're just not writing those tests most of the time if you didn't write them up front.
What is TDD?
-
What is TDD?
Test driven development. Having a well designed automated test, and then developing until the test succeeds.
-
Test driven development. Having a well designed automated test, and then developing until the test succeeds.
Ah thanks. That sounds like not that bad of an idea, but for the scale that my projects are at thus is quite an overkill. I usually try if it works in The best case sz scenario and then try to deliberately break it by calling certain functions with garbage as parameters.
-
Writing the tests first, or at least in tandem with your code, is the only way to fly. It's like publishing a proof along with your code.
it sounds trite: make the tests fit the code. Yes, it's a little more work to accomplish. The key here is that refactors of any scale become trivial to implement when you have unit-test coverage greater than 80%. This lets you extend your code with ease since that usually requires some refactor on some level.
This! Also, it's a solid base to stand on when you want to optimize your code. Performing optimizations becomes much easier, quicker and fraught with errors once you have a unit test suite that will instantly tell you whether your change is working or not.
-
Its definitely a bad idea writing new code that builds up on your old code, that has not been tested properly, because you quickly have to start debugging multiple layer is code at once.
Lol I just started refactoring my codebase into a new directory to clean up my poorly stored logs and other scripts
-
Ah thanks. That sounds like not that bad of an idea, but for the scale that my projects are at thus is quite an overkill. I usually try if it works in The best case sz scenario and then try to deliberately break it by calling certain functions with garbage as parameters.
No project is too small for tests
Tests double as your documentation for your intent
Take it from me who has 20+ years of personal projects behind me, the ones that I've kept around are typically the ones that have some form of test suite.
It's easy to build on something if you know you're not breaking something in the process
-
No project is too small for tests
Tests double as your documentation for your intent
Take it from me who has 20+ years of personal projects behind me, the ones that I've kept around are typically the ones that have some form of test suite.
It's easy to build on something if you know you're not breaking something in the process
Yeah of course I Am testing. I Am usually just not writing very extensive tests. I try to break it as much as possible with as little effort and try then to prevent it from breaking.
-
Lol I just started refactoring my codebase into a new directory to clean up my poorly stored logs and other scripts
That one is always nice when you actually do the cleanup and then have much less files to care about.
-
Its definitely a bad idea writing new code that builds up on your old code, that has not been tested properly, because you quickly have to start debugging multiple layer is code at once.
Opposing opinion: If it’s legacy code, and no-one has found a bug yet, it works as intended.
No, I don’t mean that ironically.
-
Opposing opinion: If it’s legacy code, and no-one has found a bug yet, it works as intended.
No, I don’t mean that ironically.
wrote last edited by [email protected]It's refreshing to see someone on social media who doesn't dismiss code as "outdated" just because of its age.
-
Its definitely a bad idea writing new code that builds up on your old code, that has not been tested properly, because you quickly have to start debugging multiple layer is code at once.
wrote last edited by [email protected]Test driven development means you write the test case first and then never write any additional tests.
-
Its definitely a bad idea writing new code that builds up on your old code, that has not been tested properly, because you quickly have to start debugging multiple layer is code at once.
-
Test driven development means you write the test case first and then never write any additional tests.
I usually do it thenother way around
-
Writing the tests first, or at least in tandem with your code, is the only way to fly. It's like publishing a proof along with your code.
it sounds trite: make the tests fit the code. Yes, it's a little more work to accomplish. The key here is that refactors of any scale become trivial to implement when you have unit-test coverage greater than 80%. This lets you extend your code with ease since that usually requires some refactor on some level.
Writing the tests first also ensures that the test actually fails when you expect it to. I've seen test suites that were silently failing for years because they were (presumably) written after the fact and people just assumed that they tested what they said they did. Went in for some other clean up, stared at the test for 10 minutes wondering "how did this ever pass", and then came to realize that test assertions in Jest inside a forEach apparently don't run in the context of the test and failures won't make the test fail. Changing the forEach to a for...of made it all fail immediately.
-
It's refreshing to see someone on social media who doesn't dismiss code as "outdated" just because of its age.
There are dozens of us! But also, I have a masochistic tendency to update my old code to use the new language features and make it somewhat readable.
-
Yeah of course I Am testing. I Am usually just not writing very extensive tests. I try to break it as much as possible with as little effort and try then to prevent it from breaking.
That sounds like you're doing TDD, albeit informally.
-
That sounds like you're doing TDD, albeit informally.
From what I understand the difference between how I code and what has Ben described as TDD in this thread is, that I set up everything first and then try to think of ways people could break the code and then test these vases/try to prevent them.
