Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That doesn't mean your data/db access needs to be in the same project, or tests as the rest of the application... if you haven't touched the db bits, don't run the db tests.

It's about creating appropriately sized discrete modules.



One of things unit-tests gives is fearless refactoring. When you can easily change behavior in one module and tests shows other modules are not affected (or affected). When you test only one module/layer you don't see the whole picture and such tests are much less representative and useful.


Only fearless if you're not using mocks/stubs/etc. With mocks and stubs in a dynamically typed language it's not quite as fearless.


Dynamically typed languages are an anti-pattern, where they are not unavoidable - i.e. web front-ends.


Bollocks. If your database schema changes right at the heart of the data model, a load of unit tests are not going to save you from some serious hassle.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: