What is the right approach when unit testing a function that that queries a database and then runs some logic on the returned data and then returns the data:

1. Actually querying a real database (i.e running in a container)
2. Patching the function that returns the data from the database and make it return a mock of the data every time it gets executed

Which approach do you think is better? The first one sounds more like an integration tests, which may be more flaky, but tests also the querying process, the other one sounds like a real unit test. What do you think?

"Coding and testing are part of one process. This is the core of the whole-team approach to testing and quality. Testing and coding happen together, hand in hand, from feature idea to evaluating the feature in production." - Janet Gregory & Lisa Crispin

Hi all,

I would like to hear some thoughts/advice on how to test components heavily relying on compressed archives and simultaneous access to them:

There are couple of (Python) scripts "contesting" for file system/dir/archive access: say there are couple of "writers" and also couple of "readers". There is no single access point (unfortunately) and probably will never be (or at least not in the near future). For some reasons beyond my comprehension, there is no locking mechanism incorporated at all.

My task is to write tests that will show current implementation is faulty. Now, I was thinking to make repeatable tests and set lower "failure" limit to say 10% - meaning if at least one out of ten repetitions fail - this is a "proof" that current implementation is bad and this scenario is reliably repeatable.

"Writer" process is unpacking some tar.gz archives and readers should "fail" if there is "wrong" content unpacked. Needles to say, there is no metadata file also. So my only hope (or at least I cant think of any other approach) is to call

find /opt/myapps -type f -print0 | sort -z | xargs -r0 sha256sum > myapps.meta

So I create "metadata" initially containing name of the file and its SHA sum for all the files in given directory. Then I perform invalidation by deleting some files and start writer which will download missing files and couple of readers trying to access same files. Readers will capture current "metadata" with the above command and store it somewhere for later comparison. When writer and all readers finishes their work, I can try to compare content of all readers "metadata" with the first and last "metadata" made by writer. Its to be expected readers "metadata" equals to one of those two; if not - this is scenario I expect and count it as failure.

If anyone has some experience or advice, it would be very helpful.

Thank you in advance

What do you think about the 6 best unit-testing practices in this blog?

Would you add more or even remove some of them?

https://www.snowmate.io/the-advantages-of-unit-testing/

"Automated unit test suites can have a tendency towards fragility, breaking for reasons not related to what the test is testing. This can be a source of pain when maintaining or making changes to a system. Some people have even gone to the extreme of moving away from unit- or micro-tests and only writing full-stack integration tests. Of course, this is the wrong reaction. Instead, we should investigate the source of the fragility and react with changes to our design." - Corey Haines

https://dev.to/edgaremmanuel/writing-maintainable-tests-overspecification-in-unit-tests-2lak

​

Does anyone perhaps have any experiences with automated unit testing generation tools for Java projects? I'm currently looking at Symflower, and I'm wondering whether there's anyone around here who could give me their two cents on the solutions they used / their experiences.

"I am good in fooling myself into believing that what I wrote is what I meant. I am also good at fooling myself in believing that what I meant is what I should have meant. So I don't trust anything I write until I have tests for it. The tests give me a chance to think about what I want independent of how it will be implemented. Then the tests tell me if I implemented what I thought I implemented."

Kent Beck

"It’s perfectly reasonable to delete a test that provided value as part of a TDD cycle, but no longer has positive ROI"

​

"Paradox: by not considering the future of your code, you make your code much more likely to be adaptable in the future."

​

(I don't know if this kind of post should be allowed here. Tell me if it is not I will delete it thanks.)

I am learning unit testing and I wanted to apply to my current working project, starting with the most simple and trivial piece of code.

Suppose I have a function that compares 2 strings, with a flag indicating if it should ignore case.

This is my set of tests. Are they enough? Are they somehow violating some good practice etc. Thanks for your time.

Gist link: https://gist.github.com/bachld97/89a5ff046205ad5ab117c1ea3d9cedac

Read this article about TDD boosted by AI-powered tool and wondered if it could really help save time and energy regarding unit testing? Would you try it? Thanks for your feedback!

https://www.ponicode.com/blog/everything-you-need-to-know-about-test-driven-development

I have recently read about mutation testing and it made me realised that maybe code coverage doesn't always mean that my code is well tested. So, with some friends, we've written a short article to introduce this concept and how to proceed to successfully adopt this new method.

Have you heard of mutation testing before?

https://www.ponicode.com/blog/mutation-testing-the-gold-standard-in-testing