3 ms·

My favorite interview question. No, I mean when I'm being interviewed. The sheepish grins let me know I'm not alone. Best ideas IMO (no particular order): - m

by uticus 4y ago

My favorite interview question. No, I mean when I'm being interviewed. The sheepish grins let me know I'm not alone. Best ideas IMO (no particular order): - make SQL dumber, move logic that needs testing out of SQL - use an ORM that allows composing, disconnect composition & test (ie EF for .NET groups, test the LINQ for correct filtering etc, instead of testing for expected data from a db) (I see this has already been recommended elsewhere) * edited formatting

javaunsafe2019 4y ago
You mean using interfaces and integration tests?
- uticus 4y ago
  > using interfaces Kinda, but personally I describe as using LINQ queries. The dbcontext just isn't hooked up. It's a method that takes in an IQueryable<T> (there's the interface I suppose) and outputs a filtered IQueryable<T>. The unit test (see my next response) provides a test collection and expects a certain result. > and integration tests No, unit tests
  - joshschreuder 4y ago
    Just as a real world (somewhat) counterpoint to this - you need to be very careful about performance metrics in particular. Functionality is pretty easy to verify with LINQ / mock data sets (though it is also easy to mock things in a way that aren't representative of real data by mistake) but the performance characteristics of a real SQL engine vs. unit testing in this way can lead to some real gotchas once it's deployed. Particularly if you're using an ORM, multiple enumerations over database queries, strange ORM choices in joins/exists/whatever can absolutely murder performance. I would still recommend having integration and/or performance testing downstream of these types of unit tests though I agree they are useful.
    - uticus 4y ago
      great point and agree - and, actually it argues even better against my point #1 about moving business logic out of SQL queries.
zip1234 4y ago
EF core makes it simple to test against a real sqlite db. It is super fast to run the tests and gives a reasonably realistic outcome.
- uticus 4y ago
  It does and I understand. But in my experience most of what should be tested is not "does the database contain x?" but "does this where clause filter y?" Those sorts of things are programmed in EF by LINQ queries. All I'm saying is, test the LINQ queries the same way you would test non-EF LINQ queries. LINQ doesn't require a database.
postalrat 4y ago
Test it by not testing it! Genius!
pharmakom 4y ago
Interesting. We have totally different philosophies here. 1. Moving logic out of SQL can break transactionality and hurt performance (more data leaves the DB) 2. ORMs hide the SQL from you, making all sorts of other things harder My favoured approach is to test my application against a real local database, built from a fresh snapshot each time. I do not change my application code to make testing easier. The application code is optimised for maintainability - so simplicity and ease of reading.

by uticus 4y ago

javaunsafe2019 4y ago

You mean using interfaces and integration tests?

uticus 4y ago
> using interfaces Kinda, but personally I describe as using LINQ queries. The dbcontext just isn't hooked up. It's a method that takes in an IQueryable<T> (there's the interface I suppose) and outputs a filtered IQueryable<T>. The unit test (see my next response) provides a test collection and expects a certain result. > and integration tests No, unit tests
- joshschreuder 4y ago
  Just as a real world (somewhat) counterpoint to this - you need to be very careful about performance metrics in particular. Functionality is pretty easy to verify with LINQ / mock data sets (though it is also easy to mock things in a way that aren't representative of real data by mistake) but the performance characteristics of a real SQL engine vs. unit testing in this way can lead to some real gotchas once it's deployed. Particularly if you're using an ORM, multiple enumerations over database queries, strange ORM choices in joins/exists/whatever can absolutely murder performance. I would still recommend having integration and/or performance testing downstream of these types of unit tests though I agree they are useful.
  - uticus 4y ago
    great point and agree - and, actually it argues even better against my point #1 about moving business logic out of SQL queries.

zip1234 4y ago

EF core makes it simple to test against a real sqlite db. It is super fast to run the tests and gives a reasonably realistic outcome.

uticus 4y ago
It does and I understand. But in my experience most of what should be tested is not "does the database contain x?" but "does this where clause filter y?" Those sorts of things are programmed in EF by LINQ queries. All I'm saying is, test the LINQ queries the same way you would test non-EF LINQ queries. LINQ doesn't require a database.

postalrat 4y ago

Test it by not testing it! Genius!

pharmakom 4y ago

Interesting. We have totally different philosophies here. 1. Moving logic out of SQL can break transactionality and hurt performance (more data leaves the DB) 2. ORMs hide the SQL from you, making all sorts of other things harder My favoured approach is to test my application against a real local database, built from a fresh snapshot each time. I do not change my application code to make testing easier. The application code is optimised for maintainability - so simplicity and ease of reading.