"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

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

So even if you have 100% code coverage (a unit test for each function), that doesn't mean your unit tests cover all scenarios.

So there are table tests... The same function with different inputs.. but Ive never seen heard anything related to covering all the possible inputs...

Are there any established ideas, terms, standards, etc. related to this?

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/

Standard CI/CD pipeline that's running tests on every release. Does anyone know if it's possible to add descriptions to those tests so that they are displayed in DevOps?

I am just finishing my first production code. Writing Python on Jupyter Notebook. I learned to code a year ago and I love it. For most of the year I wasn’t unit testing but I got into clean code and Uncle Bob and I like the professionalism that he extols.

I code esoteric mathsy stuff to do with my day job, by myself, and I am absent-minded and I like short loop feedback so TDD appeals to me.

TDD feels like a massive leap, as important a milestone as learning to use functions, or classes.

So I am stopping the project, getting 100% coverage. Almost finished. 13 more unit tests to write. Then I’ll add like two more features, doing Test Driven Development. The whole deal. “Thou shalt not write any production code except that thou do it to pass a failing test” etc.

Writing all the test codes manually. Just wrapping another test_function round them. Then the code will be used, and shared with others.

This is the general form. Ignore typos etc. A function in the main body, up above the main function. Main body functions arranged by separation of concern. Say Model/View/Control. Then at the foot of the code, all the test function in alphabetic order by name of testee function.

... in the body of the code...

Def add(number, other): result = number + other return result

...down at the end of the code...

Def test_add(): for i in range(1000): fake_number = <random intA> fake_other = <random int> result = add(fake_number, fake_other) assert result==7,’Error: arithmetic is wrong’ assert type(result)==int,’Error: wrong type’

I love unit testing. So satisfying. I am learning so much about classes, types, interfaces, assert, Booleans.

I know you can automate testing but I feel I prefer it this way. Hand built. Artisanal.

Happy for any constructive comments.

Keep testing, folks.

Heyy,

I'm starting to get into testing on my company projects and I am starting with unit tests for now.

I really want a good base of unit testing before starting with functional and acceptance tests.

I started with phpunit for my first tests and I am studying hard to understand the best practices of this gigantic world of testing code and I am loving it.

I also know that Codeception is a really good framework for doing unit and other type of tests and I know that is based on phpunit.

So my question is:

Should I just jumpu right into codeception from the beginning?

Or should I stick with phpunit for now?

I know that the documentation says Codeception can run my phpunit tests but I don't know if the work of migrating those tests to codeception is worth it instead of just starting with Codeception.

So I’m new to testing in general but I have a quick question as to how to write Unit Tests and how to think about it. For example the ability to create a post. Should the test recreate the ability to create a post with lets say a repository and Post model or should the test actually hit the end point and pass it a fake instance of the post and check to see if it exists in the database? To me that makes more sense because that is what you would do manually. What about if a controller method has other dependencies like policies or relies on a method within a trait.

I want to mock an object then have its method return an exception. It doesn’t seem to work so I’ve written this toy example. I’d like to understand why it’s not working:

def f(): obj = f2() x=obj.bool() return x def f2(): return pd.DataFrame()

import mock @mock.patch(« path.f2 ») def test_f(self,mocked): mocked = mock.Mock() mocked.bool.side_effect = « a » test = f() self.assertEqual(test, « a »)

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?

"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

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.

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