4 ms·

Sorry for such a juvenile question (I've only worked on small projects by myself before, but I'll be at my first internship with a large company ay the end of t

Sorry for such a juvenile question (I've only worked on small projects by myself before, but I'll be at my first internship with a large company ay the end of this month), but when should I even write unit tests? And should I write them for every function? Even the trivial ones? What defines trivial? Also, how about functions that write to a database? Should I refactor the code to separate the db writes and the computation, or just wipe the db after each test? I feel like unit tests could be a big help for my code, but how should I approach them? I just can't seem to justify the time it takes to come up with cases for everything.

mod 9y ago
Always write them when the code will actually be used. You typically test all "trivial" functions, partly because they're easiest to test and sometimes very easy to screw up. It can be much harder to properly test non-trivial functions. Often you want to split them into smaller, testable units. Functions that write to database get tested. The tests spin up a temporary test database and run against that. See rails for an example. Often just against sqlite3 or something, but of course that's configurable. You can justify them because tests save time. They make starting slower (especially when you're new to testing) and they make editing and altering much, much faster. They also lead to more reliable applications on average, and the ability to make changes quickly. I don't follow my own advice, because I'm lazy. But I really wish I tested every bit of code that I could. And it's the stupid kind of lazy--testing would make my life easier, all things considered.
wcummings 9y ago
Next time you are fixing a bug, write a failing test which reproduces the bug before making any other changes. Don't overthink it, automated tests should save you time. Write them to replace tedious manual tests. If you weren't going to test it anyway, don't bother.
imauld 9y ago
Write them for everything (I'll note some exceptions). Use code coverage tools to see what parts of your code are not being hit by tests. You'll find some surprises there (tests not actually testing what they say they do). When something breaks write a test that would have found the bug, and then fix it. A good test suite will save you tons of time. If a piece of code is hard to test, it's bad code (lot's of branching logic, doing way too much in oe function/method, managing/changing too much state). Re-write it so it's easy to test. However, don't test the compiler/interpreter and don't test your framework/libraries. Tests shouldn't look like this: def test_foo(): foo = Foo(a=1, b=2, c=3) assert foo.a == 1 assert foo.b == 2 assert foo.c == 3 This test will never fail and won't tell you anything. Don't test your dependencies code if you're using active, popular packages. Test that your code passes in the right values, and handles any errors that could happen in a reasonable manner. The time savings you can get out of a good test suite are almost limitless. Good test save lots of time in development and prevent broken things from making it to production.

mod 9y ago

Always write them when the code will actually be used. You typically test all "trivial" functions, partly because they're easiest to test and sometimes very easy to screw up. It can be much harder to properly test non-trivial functions. Often you want to split them into smaller, testable units. Functions that write to database get tested. The tests spin up a temporary test database and run against that. See rails for an example. Often just against sqlite3 or something, but of course that's configurable. You can justify them because tests save time. They make starting slower (especially when you're new to testing) and they make editing and altering much, much faster. They also lead to more reliable applications on average, and the ability to make changes quickly. I don't follow my own advice, because I'm lazy. But I really wish I tested every bit of code that I could. And it's the stupid kind of lazy--testing would make my life easier, all things considered.

wcummings 9y ago

Next time you are fixing a bug, write a failing test which reproduces the bug before making any other changes. Don't overthink it, automated tests should save you time. Write them to replace tedious manual tests. If you weren't going to test it anyway, don't bother.

imauld 9y ago

Write them for everything (I'll note some exceptions). Use code coverage tools to see what parts of your code are not being hit by tests. You'll find some surprises there (tests not actually testing what they say they do). When something breaks write a test that would have found the bug, and then fix it. A good test suite will save you tons of time. If a piece of code is hard to test, it's bad code (lot's of branching logic, doing way too much in oe function/method, managing/changing too much state). Re-write it so it's easy to test. However, don't test the compiler/interpreter and don't test your framework/libraries. Tests shouldn't look like this: def test_foo(): foo = Foo(a=1, b=2, c=3) assert foo.a == 1 assert foo.b == 2 assert foo.c == 3 This test will never fail and won't tell you anything. Don't test your dependencies code if you're using active, popular packages. Test that your code passes in the right values, and handles any errors that could happen in a reasonable manner. The time savings you can get out of a good test suite are almost limitless. Good test save lots of time in development and prevent broken things from making it to production.