A few aspects I would like to touch on.
I work in a field where lots of code is written, but hardly ever tested. This is because we are foremost scientists who try to solve problems with code
I think this is common in science. And I think it's only partly due to lack of courses or motivation.
I think the main reason is that a lot of scientific code is more ...
As the story goes accoring to Uncle Bob (you can read it here currently), in the 1950s-60s, the programmers who wrote the code for the Mercury space capsule wrote their unit tests in the morning and made them pass in the afternoon.
If lives and billions of dollars are involved, it is just common sense do to rigorous testing. That being said, if rigorous ...
would you trust results of a complex software with many hundreds or
thousands of functions without a single unit test?
I would not.
But a properly written set of unit tests is only one side of it.
Unit tests should be complemented by black box end-to-end tests that cover major functionality.
would you trust the model to make predictions?
Now when you know ...
It's something you can actually test scientifically. You don't have to rely on arguments from the Internet. Write unit tests and see if they catch errors your manual testing didn't. See if they reduce the time to find errors.
Unit testing wasn't very common in software development until the early 2000's, so anyone who has been doing this for longer than ...
Are there other way to solve the external dependency issue?
DynamoDB is tightly coupled to Amazon. Amazon built it. Unless you can identify a higher level of abstraction, just leave your class as it is. Identifying a higher level of abstraction involves analyzing all of the consumers of InternalDataStorageClient and possibly eliminating all references to ...
you would write for each class tests in a separate file that ensure compatibility for an implementation
Don't be dogmatic about this. If you have two implementations which under all circumstances should have the same functionality, then just write one set of and run the tests twice with the different implementations.
Is it possible/advisable to combine unit testing and integration testing?
Doing both unit testing and integration testing? Overwhelmingly yes.
Mashing them together in a single test suite? Not advisable.
Based on your comment, it seems you already understand the purpose of both, so I won't repeat that here. But I do want to address your suggestions that ...
The other answers explain how to make sure the function is random, but don't talk about testing for correctness.
For example, if the function is supposed to generate a random number between 0 and 1, make sure the result is between 0 and 1. If it's supposed to shuffle a list, make sure the input and the output have the same elements. Etc.
Assuming that with "google tests" you mean tests written with the Google Test C++ testing framework, I'm pretty sure you can use it for system tests, and you can definitely use pytest for unit tests (but for Python code).
My guess is that since system tests don't need to match the language the system is written in (by definition they should access ...
First you should distinguish the different kinds of tests. Each kind most likely requires a different test plan, test schedule, tester resources.
These don't test the API but internal functionality. You just need them. Like the next category, they should be automated, but triggered by developers to ensure that newly written code works as desired ...
Adversarial vs Aspirational
I think this is the problem you've tripped over.
In TDD the process is this:
Write an Aspirational test describing the behaviour desired.
Write the code in the unit that make this test pass, while keeping the other tests passing.
Review the Aspirations and make sure they are what you aspire too.
Update your Aspirations
You should write enough tests so that if, say, function3 breaks it wont take long to realize that the bug is in function3.
It's good to have a test exercising every public interface if for no better reason then it documents how to use the interface. But remember, the main value of tests is that they help you fix things. Write tests that make things easy to ...
Technically speaking, if there’s only one integration, you could simply have one integration test. For simple code, like your example, this may prove sufficient.
However, there are plenty of reason that could justify testing the integration at each level. For example:
there are in reality several integration steps. For example when multiple teams are ...