|
toiletbrush posted:I've got a co-worker who's like this except instead of asking for help he'll slowly and painstakingly progress from just running the same test again and again to cleaning and rebuilding to restarting Visual Studio to finally rebooting this entire machine to try and fix it, rather than just reading the error message that tells him exactly what he's doing wrong. reading error messages is genuinely a learned skill
|
![]() |
|
![]()
|
# ? Jun 7, 2023 13:24 |
|
DONT THREAD ON ME posted:testing integrations with your persistence layers is a difficult and frustrating problem, imo. i have yet to discover a method of unit testing sql queries that gives me full confidence that they'll perform the way i want.
|
![]() |
|
Sagacity posted:why not just spin up a docker container containing postgres (or whatever you use), run your migrations against it and unit test all your queries? then the rest of the code can just run with whatever fake in-memory repository you use, but at least you know that a) your migration work and b) your queries are valid it's slow and error prone. i think it's still worth doing but it's pretty gross.
|
![]() |
|
Sagacity posted:why not just spin up a docker container containing postgres (or whatever you use), run your migrations against it and unit test all your queries? then the rest of the code can just run with whatever fake in-memory repository you use, but at least you know that a) your migration work and b) your queries are valid this is pretty much what we do. when the ci pipeline runs it spins up a db instance and runs all the migrations. test cases for functions that have a part of their business logic written in sql usually start a transaction, insert the test data they need, call the function and roll the transaction back again. more complex queries are usually broken out into separate functions, which get a bunch of test cases just for that query. treating the database as a service that just returns data and can be mocked out weirds me the hell out. sql queries are functions that return values, of course you can and should test that they behave as intended given a certain input.
|
![]() |
|
DONT THREAD ON ME posted:it's slow and error prone. i think it's still worth doing but it's pretty gross. works great here ![]() this wacky behavior i saw today is the first time i've run into a problem with it in months.
|
![]() |
|
if you mock the db or use an ad hoc db containing only the minimum required to test, then you are going to have all sorts of problems when you move to production where the tables have actual data volume in them and the query planner behaves completely different. for real qa you need a sanitized copy of your prod db, updated regularly, on a server with similar performance to your actual production db server
|
![]() |
|
yeah let me just load up a 300tb database whenever we run tests
|
![]() |
|
DELETE CASCADE posted:if you mock the db or use an ad hoc db containing only the minimum required to test, then you are going to have all sorts of problems when you move to production where the tables have actual data volume in them and the query planner behaves completely different. for real qa you need a sanitized copy of your prod db, updated regularly, on a server with similar performance to your actual production db server sure, but that kind of performance testing is a whole different category of testing. a good test tests one thing. testing that a query does the intended thing logically is an entirely different question from whether it performs sufficiently well in a production-like environment, or whether it plays nice transactionally for that matter.
|
![]() |
|
unit testing should run in as predictable an environment as possible. attempting to write unit tests against production data sounds like an exercise in constant frustration when your test scenario fails due to some valid change to the live data - not to mention how much longer your tests will take to run compared to mocking a data source
|
![]() |
|
yeah there's just no very satisfying solution.
|
![]() |
|
we use jOOQ for our SQL stuff in java and when we make changes to the schema we spin up a docker container, run migrations, then have jOOQ generate the Record/Table models needed for typesafe queries, then commit those into the project. it makes it hard to write a broken query because you don't get to use strings
|
![]() |
|
TheFluff posted:sure, but that kind of performance testing is a whole different category of testing. a good test tests one thing. testing that a query does the intended thing logically is an entirely different question from whether it performs sufficiently well in a production-like environment, or whether it plays nice transactionally for that matter. ya of course you can do the unit testing with mocks, but that's like a minimum requirement. it seems like a lot of people stop there and pat themselves on the back for their code coverage metrics. not sure why they do that, since unit testing is drudgery while performance testing is challenging and interesting
|
![]() |
|
toiletbrush posted:I've got a co-worker who's like this except instead of asking for help he'll slowly and painstakingly progress from just running the same test again and again to cleaning and rebuilding to restarting Visual Studio to finally rebooting this entire machine to try and fix it, rather than just reading the error message that tells him exactly what he's doing wrong. ive definitely done the opposite - spend half an hour resetting settings to try and work out why the solution won't start properly in debug only to remember that "hey, sometimes VS gets flakey and you just gotta restart it". in this case, the error is from an internal library that was actually written by a Not-Terrible programmer and has custom error classes that tell you exactly what is going on, and logs out the output of what it's doing so you can see where the error is. i strongly suspect the problem is that although they say they're running it with elevated permissions, they actually aren't and so it can't write the machine key needed for the config encyption library to work
|
![]() |
|
Current terrible programmer status: saved output to folders in the format 'year-minute-day' instead of 'year-month-day' lol
|
![]() |
|
Asleep Style posted:Current terrible programmer status: saved output to folders in the format 'year-minute-day' instead of 'year-month-day' lol let those who have never sinned cast the first stone
|
![]() |
|
gonadic io posted:let those who have never sinned cast the first stone I did this. Turns out in .NET you want "yyyy-MM-dd", not "yyyy-mm-dd"
|
![]() |
|
Asleep Style posted:Current terrible programmer status: saved output to folders in the format 'year-minute-day' instead of 'year-month-day' lol Just wait until somebody uses YYYY instead of yyyy in a Java SimpleDateFormat!
|
![]() |
|
CPColin posted:Just wait until somebody uses YYYY instead of yyyy in a Java SimpleDateFormat! i've done this
|
![]() |
|
Is there a conference thread? Please tell me someone else here is at codemash tonight
|
![]() |
|
CPColin posted:Just wait until somebody uses YYYY instead of yyyy in a Java SimpleDateFormat! The more I learn about date/time issues the more I'm amazed that anything works. What a minefield.
|
![]() |
|
Asleep Style posted:The more I learn about date/time issues the more I'm amazed that anything works. What a minefield. just wait until we get to mars! and also regularly travel fast enough to experience noticeable relativistic effects (satellites already kind of do)
|
![]() |
|
if you're lazy like me you can just janitor up an SQL server and fill it with data, then turn it on when you want to use it. I do this in EC2 and use Travis to start/stop it. If you're dealing with 10s of terabytes of data obvs this gets pretty expensive because you pay for cloud disk all the time but it's still probably worth it for realistic testing. If you want to be super complete and you don't mind long running builds the nirvana is starting with an empty database, filling it with data, then running all the unit tests against it.
|
![]() |
|
What the hell sort of "unit tests" are you writing that you need to have them interact with a database?
|
![]() |
|
absolute unit tests
|
![]() |
|
Jabor posted:What the hell sort of "unit tests" are you writing that you need to have them interact with a database? technically it's an integration test, but any non-trivial sql ought to be tested
|
![]() |
|
CPColin posted:absolute unit tests pretty good
|
![]() |
|
I’m always surprised to see so much emphasis on unit tests over other types, when in my experience they are useful for catching regressions and absolutely nothing else. It’s like the least interesting, least difficult type of testing
|
![]() |
|
They're like the easiest ones to write when you're writing new code and the hardest to write when you're trying to cover existing code that has poor coverage.
|
![]() |
|
DELETE CASCADE posted:I’m always surprised to see so much emphasis on unit tests over other types, when in my experience they are useful for catching regressions and absolutely nothing else. It’s like the least interesting, least difficult type of testing unit test where I work means "thing kicked off by junit that is a convoluted check for a bug we just fixed and probably won't run into again". we want to just do continuous stress tests of the whole product but it's hard to get the resources behind that.
|
![]() |
|
DELETE CASCADE posted:I’m always surprised to see so much emphasis on unit tests over other types, when in my experience they are useful for catching regressions and absolutely nothing else. It’s like the least interesting, least difficult type of testing the only time I’ve felt successful using unit tests was when I was making a thing that needed to be interoperable with other, existing implementations. the test suite was thorough enough to give me the confidence that passing all the tests meant my implementation worked. also I didn’t actually have to write any of the tests, that was a big help
|
![]() |
|
jit bull transpile posted:unit test where I work means "thing kicked off by junit that is a convoluted check for a bug we just fixed and probably won't run into again". we want to just do continuous stress tests of the whole product but it's hard to get the resources behind that. yeah we have those too. but we also have unit tests written by the original developer of a class, so that it passes code coverage. if one such test fails due to a programming error, ie an error in translation from concept to code, the programmer will fix it before submitting their code+tests. if a test fails because of a misunderstanding of the intended behavior, the programmer will align the code and the test to the same misunderstanding. therefore the test always passes, unless a regression occurs which now violates the programmer's tested assumptions. in no case have we verified that the code delivers as expected when deployed in an actual production environment, which is where 99% of the bugs appear in my experience, and more unit tests won't ever fix this
|
![]() |
|
The unit tests state the behaviour the programmer intended. They then ensure that when the code is changed later, the only behaviours that change are the ones that the programmer intends to change. That has a lot of value with long-lived code that will be changed many times over its lifespan. If you're just writing a prototype that will be thrown away rather than maintained or extended then I guess they're not so useful, but my experience with such prototypes is that they're often more permanent than you originally intended...
|
![]() |
|
the #1 thing unit tests do is find regressions. if your tests are good, then its great. if your test are wrong, then its still good because you're ensuring it continues to work like the previous version. if you want unit tests to also verify design functionality you need to have someone (preferably another team) write the tests.
|
![]() |
|
Jabor posted:What the hell sort of "unit tests" are you writing that you need to have them interact with a database? fine, just call them "tests" then. most web apps are in a somewhat unhealthy codependent relationship with their database, so a lot of business logic is usually written in a mix of sql (or something that generates sql) and whatever application language you're using. of course the business logic needs tests, and to test that the parts written in sql do what they're supposed to be doing, you need a database. how else would you test them?
|
![]() |
|
Jabor posted:What the hell sort of "unit tests" are you writing that you need to have them interact with a database? but I'm probably an outlier
|
![]() |
|
Shaggar posted:if you want unit tests to also verify design functionality you need to have someone (preferably another team) write the tests. if i have a team of people capable of understanding another team's codebase well enough to write tests within it that meaningfully exercise design corner cases of a spec they also had no hand in writing, then i'd better give them something more interesting to do than writing unit tests all day, or they'll quit
|
![]() |
|
meanwhile at my job: the gently caress's a unit test? is that something qa does?
|
![]() |
|
DELETE CASCADE posted:if i have a team of people capable of understanding another team's codebase well enough to write tests within it that meaningfully exercise design corner cases of a spec they also had no hand in writing, then i'd better give them something more interesting to do than writing unit tests all day, or they'll quit that's why nobody does good qa
|
![]() |
|
unit testing is good because it forces you to design your code in a unit testable way, which encourages dependency injection and other good design patterns. For instance: code:
DONT THREAD ON ME fucked around with this message at 02:33 on Jan 11, 2019 |
![]() |
|
![]()
|
# ? Jun 7, 2023 13:24 |
|
there's a point where adding layers upon layers of interfaces on everything feels like it's diminishing return on programming time sometimes an int is just an int
|
![]() |