4 ms·

So we have a REST API created using node and most of the job happens on Postgres and sql files. Basically, 95% of the methods depend on database [and it's curr

So we have a REST API created using node and most of the job happens on Postgres and sql files. Basically, 95% of the methods depend on database [and it's current state]. How can I unit test this? I've given up on unit tests. They wouldn't make any sense. E2E tests are helping us a lot but I had several attempts to have unit tests but they don't make any sense at all.

abritinthebay 9y ago
Those methods are still data in, data out tho right? So test that with mocked data. Unit tests should be able to run with no network connection, no other service, just your test file + data. Otherwise at that point you’re doing integration testing, not unit tests.
- emilsedgh 9y ago
  Let's say I have a `SomeEntity.get` function. Basically it gets an array of id's and calls the database and fetches those entities. ~10 lines of Javascript code. 40 lines of SQL. Which also depends on the state of the database. So what do I gain by mocking the database? Making sure those 10 lines of javascript work fine? In a vacuum? They are the 10 easy lines anyways which are covered by my E2E test. What matters is the SQL and how it behaves in different states of the database.
  - abritinthebay 9y ago
    And that’s why you test the DB with an integration test (and likely a functional test too). For your unit test you’d just mock the dB call and make sure that function called the “db” and returned the faux data. That’s it. No one said unit tests had to be complex or test the whole stack. Quite the opposite actually.
- filleduchaos 9y ago
  At that point, that's just testing for the sake of testing, which is just silly - nobody needs you to prove that the compiler/interpreter/library/framework in fact works the way its maintainers have already tested it to work
  - abritinthebay 9y ago
    Yeah, the most you should be testing there is “it’s a function and it calls the (mock) db and returns data of type whatever”. That’s like... 2 minutes of test writing, tops? I think that we really need to discuss unit testing as a group more. Specifically: what a unit test isn’t. It’s amazing how popular some misguided and ill-informed ideas about them are...
mason55 9y ago
Yes, if you look at the article, specifically Anti-Pattern 3, you'll see that different types of applications require different types of tests. If your units of work are "retrieve data for a list of IDs" and "store this data in the DB" then there probably isn't a lot of unit testing to be done. You probably have some data cleansing or validation functions that you can unit test, and probably some domain-specific data transformation that you can unit test. But most of your testing should be integration testing because the important thing is that the piece that's reading the data and the piece that's writing the data work the same way. If you only have unit tests that set themselves up and tear themselves down then you'll never find a bug where, e.g., the columns get switched around on a write.
corpMaverick 9y ago
IMHO. This is mostly integration tests. If you have methods that have calculations or other complex logic, then write unit tests for those. Integration tests and unit tests are complementary. The mix depends on the type of code you are testing.

abritinthebay 9y ago

Those methods are still data in, data out tho right? So test that with mocked data. Unit tests should be able to run with no network connection, no other service, just your test file + data. Otherwise at that point you’re doing integration testing, not unit tests.

emilsedgh 9y ago
Let's say I have a `SomeEntity.get` function. Basically it gets an array of id's and calls the database and fetches those entities. ~10 lines of Javascript code. 40 lines of SQL. Which also depends on the state of the database. So what do I gain by mocking the database? Making sure those 10 lines of javascript work fine? In a vacuum? They are the 10 easy lines anyways which are covered by my E2E test. What matters is the SQL and how it behaves in different states of the database.
- abritinthebay 9y ago
  And that’s why you test the DB with an integration test (and likely a functional test too). For your unit test you’d just mock the dB call and make sure that function called the “db” and returned the faux data. That’s it. No one said unit tests had to be complex or test the whole stack. Quite the opposite actually.
filleduchaos 9y ago
At that point, that's just testing for the sake of testing, which is just silly - nobody needs you to prove that the compiler/interpreter/library/framework in fact works the way its maintainers have already tested it to work
- abritinthebay 9y ago
  Yeah, the most you should be testing there is “it’s a function and it calls the (mock) db and returns data of type whatever”. That’s like... 2 minutes of test writing, tops? I think that we really need to discuss unit testing as a group more. Specifically: what a unit test isn’t. It’s amazing how popular some misguided and ill-informed ideas about them are...

mason55 9y ago

Yes, if you look at the article, specifically Anti-Pattern 3, you'll see that different types of applications require different types of tests. If your units of work are "retrieve data for a list of IDs" and "store this data in the DB" then there probably isn't a lot of unit testing to be done. You probably have some data cleansing or validation functions that you can unit test, and probably some domain-specific data transformation that you can unit test. But most of your testing should be integration testing because the important thing is that the piece that's reading the data and the piece that's writing the data work the same way. If you only have unit tests that set themselves up and tear themselves down then you'll never find a bug where, e.g., the columns get switched around on a write.

corpMaverick 9y ago

IMHO. This is mostly integration tests. If you have methods that have calculations or other complex logic, then write unit tests for those. Integration tests and unit tests are complementary. The mix depends on the type of code you are testing.