I’ve never actually tried or got the point of this test stuff tbh. It didn’t exist when I started so I never really got the point of it. I tried reading up on it a bunch of times and it seemed like extra work for nothing 🤷
It seems popular though so maybe one day I’ll get around to it…
Code normally works fine after you write it and then hopefully at least test by hand. The new guy 5 years later, which do not fully grasp the extent of his actions, and the guy reviewing the code also not being too familiar with it, will not make sure everything does as intended.
Tests are correctness guarantees, and requires the code and/or the test to change to pass. They also explain how something should behave to people that don’t know. I work in a area where there are so many businesses rules that there is no one person that knows all of it, and capturing the rules as tests is a great way to make sure that rules remains true after someone else comes to change the code.
My job used to outsource a bunch of dev work to another company and oh boy did those people love their tests. I don’t get it. In my case they weren’t even using our actual database to pull data from. They had a bunch of fixture files with generic data that they would use to make a temporary sqlite db for the tests. All of the test ran perfectly with that data, not so much with the actual data. The code is there, can’t you just read it and know what will happen?
When I write something I’m never not building it and at least checking that it works and trying to break it.
Imo each test tests a specific functionality which requires a fixture set up for that. Its important that these figures mirror exactly how it would look in production or the tests are pointless.
For example customer A uses product A in a specific way it’s important that we enter customerA.settings and productA.props into the test and only test the specifics in said transaction.
There are certainly different kinds of developers writing different types of tests. I usually only write the tests first if I‘m adding a critical functionality to some method or function already present.
However having automated tests can help you when you can‘t easily understand the code or when you want to refactor that code to make sure you‘re not breaking existing functionality.
What you‘re describing with external devs often happens when these devs can‘t access the real data - plus you often want these tests to be automated, which usually brings with it the requirement of atomicity, i.e. you want one test run running in parallel with another not effecting each other. That usually doesn‘t work well with a real database (unless you really take your test engineering to the overengineered tier).
I’ve never actually tried or got the point of this test stuff tbh. It didn’t exist when I started so I never really got the point of it. I tried reading up on it a bunch of times and it seemed like extra work for nothing 🤷
It seems popular though so maybe one day I’ll get around to it…
Code normally works fine after you write it and then hopefully at least test by hand. The new guy 5 years later, which do not fully grasp the extent of his actions, and the guy reviewing the code also not being too familiar with it, will not make sure everything does as intended.
Tests are correctness guarantees, and requires the code and/or the test to change to pass. They also explain how something should behave to people that don’t know. I work in a area where there are so many businesses rules that there is no one person that knows all of it, and capturing the rules as tests is a great way to make sure that rules remains true after someone else comes to change the code.
My job used to outsource a bunch of dev work to another company and oh boy did those people love their tests. I don’t get it. In my case they weren’t even using our actual database to pull data from. They had a bunch of fixture files with generic data that they would use to make a temporary sqlite db for the tests. All of the test ran perfectly with that data, not so much with the actual data. The code is there, can’t you just read it and know what will happen?
When I write something I’m never not building it and at least checking that it works and trying to break it.
Imo each test tests a specific functionality which requires a fixture set up for that. Its important that these figures mirror exactly how it would look in production or the tests are pointless.
For example customer A uses product A in a specific way it’s important that we enter customerA.settings and productA.props into the test and only test the specifics in said transaction.
There are certainly different kinds of developers writing different types of tests. I usually only write the tests first if I‘m adding a critical functionality to some method or function already present. However having automated tests can help you when you can‘t easily understand the code or when you want to refactor that code to make sure you‘re not breaking existing functionality.
What you‘re describing with external devs often happens when these devs can‘t access the real data - plus you often want these tests to be automated, which usually brings with it the requirement of atomicity, i.e. you want one test run running in parallel with another not effecting each other. That usually doesn‘t work well with a real database (unless you really take your test engineering to the overengineered tier).