Unit Testing Practices
Debates on software testing strategies, including isolation vs integration testing, testing private methods, whether tests should drive design changes, and avoiding implementation-coupled tests.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Your tests are part of your code. Your implementation code should not make writing your test code difficult.
If you are developing your code as a small tiny functions getting stitched later. Then writing unit test cases will solve this problem too.
Tests effectively freeze requirements; you should test those things which should be preserved throughout any changes, and not test those things which should be open to change. In this case, it seems that is no real requirements for any of these 9 steps - perhaps the implementer could figure out how to do the same outcome by skipping a step or merging two steps, and the existence of unit tests for these 9 functions somehow encodes the idea that these 9 functions each are inherently needed, which
Can someone explain to me how integrating your test into the same code that your testing is a good idea?
The problem with abstractions in testing is - you should test it :)
That's interesting - I can sort of see it both ways. Would applying unit tests to the exposed functions not have sufficed?
I'd go so far as to say if your test is doing something crafty, you're doing tests wrong. Maybe in a mock or fixture, but that's a write-once sort of affair.I also don't apply DRY (don't repeat yourself) to tests. Tests should be independently readable beginning to end, no context needed. After all, the true value of a unit test is to take a block of code too complicated to easily fit in your mind, and break it down into a series of examples simple enough to fit.
Honest question: can you expand on why this is bad? Doesn't efficiency outweigh respecting feature boundaries in tests?
I think the tests should adapt to the design, not the design to the tests..
It seems like you need to call this function :) and not surprisingly, your comment is totally incorrect, tests can be implemented independent of each other regardless of the quality of the code they are testing. This doesn't mean they can run in parallel, but every test should be running independently from each other no matter what.