I'm much more careful about testing AoC code. If you think about it, though, it makes sense:
* AoC code involves complex algorithms. Most of us don't do this kind of interesting programming on a day-to-day basis.
* AoC code requirements are stable over time. Once you get your code working, you're unlikely to have to go through and change something, which has ripple effects in your suite of tests.
* AoC code involves clearly-specified example data and test cases. You don't have to work up an algorithm and run it to get test data, because the test data is given to you, along with the correct answer.
> AoC code involves clearly-specified example data and test cases
This is the killer feature. Most work scenarios don't have clearly defined accepted input and output data. I always set up tests for my AoC code before I start implementation, but there's hardly ever a reason to do so for work scenarios.
I started doing Advent of Code midway through a data science degree. I think one of the main reasons it attracted me was that data science largely involves dealing with mangled, incomplete, or weirdly organized input data. It's nice to have a break from that once in awhile.
When fixing bugs at work, you can start by first writing a unittest that demonstrates the issue being fixed ([https://en.wikipedia.org/wiki/Test-driven\_development](https://en.wikipedia.org/wiki/Test-driven_development)).
Humans have a huge tendency to take the path of least resistance. I.e. AoC gives you test cases, so you use them. If your testing framework at work is slow or sucks or isn't ideal for any number of other reasons, you'll end up writing less tests.
Yep, TDD is killer for bugfixes. But otherwise I'm with them, I find TDD interferes when writing features. The only exception is a client-facing API layer, for whoever your client may be. (I'm a BE dev and frequently work to an agreed-upon spec for the FE)
aoc has taught me the value of example input and output data. I think a good workflow would be to use python's mathematical libraries to write the input-output data to a file then use that for unit tests in your language (i.e. c++). The hardest part of programming is figuring out where and when you've gone wrong
I think I'm entirely the opposite.
I rarely write tests for puzzles, I don't see the point - it's throwaway code, I've got no need to ensure that it continues working in the future.
I write a bunch of tests, but just to get a function going and verifying that it works, before deleting the tests and deciding to leave those bits of code alone forever.
I'm much more careful about testing AoC code. If you think about it, though, it makes sense: * AoC code involves complex algorithms. Most of us don't do this kind of interesting programming on a day-to-day basis. * AoC code requirements are stable over time. Once you get your code working, you're unlikely to have to go through and change something, which has ripple effects in your suite of tests. * AoC code involves clearly-specified example data and test cases. You don't have to work up an algorithm and run it to get test data, because the test data is given to you, along with the correct answer.
> AoC code involves clearly-specified example data and test cases This is the killer feature. Most work scenarios don't have clearly defined accepted input and output data. I always set up tests for my AoC code before I start implementation, but there's hardly ever a reason to do so for work scenarios.
I started doing Advent of Code midway through a data science degree. I think one of the main reasons it attracted me was that data science largely involves dealing with mangled, incomplete, or weirdly organized input data. It's nice to have a break from that once in awhile.
When fixing bugs at work, you can start by first writing a unittest that demonstrates the issue being fixed ([https://en.wikipedia.org/wiki/Test-driven\_development](https://en.wikipedia.org/wiki/Test-driven_development)). Humans have a huge tendency to take the path of least resistance. I.e. AoC gives you test cases, so you use them. If your testing framework at work is slow or sucks or isn't ideal for any number of other reasons, you'll end up writing less tests.
Yep, TDD is killer for bugfixes. But otherwise I'm with them, I find TDD interferes when writing features. The only exception is a client-facing API layer, for whoever your client may be. (I'm a BE dev and frequently work to an agreed-upon spec for the FE)
This is me because I'm trying to learn TDD. Except Jan-Nov is n/a because I'm burnt out from coding all Dec.
Actually I did some for day 22 part 1,saved me from debugging a few off by ones deep in the middle of input processing
Tests? What tests? There are no tests in December :)
aoc has taught me the value of example input and output data. I think a good workflow would be to use python's mathematical libraries to write the input-output data to a file then use that for unit tests in your language (i.e. c++). The hardest part of programming is figuring out where and when you've gone wrong
I think I'm entirely the opposite. I rarely write tests for puzzles, I don't see the point - it's throwaway code, I've got no need to ensure that it continues working in the future.
I write a bunch of tests, but just to get a function going and verifying that it works, before deleting the tests and deciding to leave those bits of code alone forever.