5
It depends...
There is no rule that everything must be tested with unit tests, or even at all. There is however a lot of evidence that unit tests catch +75% (clarification below) of all errors.
My personal experience is that unit tests will catch +75% of errors before they get to any QA team, based on a relatively mature monolith and internal statistics. ...
5
Some of these, particularly 4, 5 and 7 are "clearly" more readable in the fluent truth style - the assertion days exactly what it does, no brainpower required. It is also worth noting that your #7 does not match the truth example: think about what happens if d contains an element foo. Sure, you can fix it, but if you got it wrong writing the question, would ...
5
You aren't required to test at the finest possible grain.
Many current discussions of unit-testing are rooted in a tradition (XP) where features are added incrementally. In other words, almost everything starts out as a "simple" function, and many of those simple functions grow in complexity over time.
So it makes sense, from that perspective, that we ...
4
The goal of unit test is not to see if it works for you, but to ensure in an automated way that what worked before still works, whatever change you make to your function.
Of course, for simple functions it’s an extra effort. But this is the price for achieving a high reliability: the idea is not to rely on the developper to decide whether a change or not ...
4
Here even the unit tests seem to be dependent on the stubs. A part of my brain says that this is an integration test rather than unit test.
ArticleService is dependent on an instance of ArticleRepository. Whether a test involving ArticleService is a unit or integration test comes down to, "does it have side effects". Use a real repository and it does. SO ...
3
According to the documentation, PyTruth claims to have more informative failure messages than some other widely-used testing frameworks in Python. (This is of course a subjective measure.)
Failure messages are very important in unit testing, and even more so in Test-Driven Development, where the failure message actually partially drives the implementation. (...
3
Doesn't matter if it's a one liner. What matters is if it's a business rule.
Boring structural glue code that connects things together isn't worth a unit test.
A business rule as simple as rejecting negatives is worth unit testing even if it's a one liner.
3
I would not say that using virtual method for mocking is a bad idea. It is yet another tool for the job.
I'm comparing mocking via interface vs delegate vs virtual method in C# in this article. As you can see virtual method option looks attractive due to the smallest code changes for supporting mocking possibility, of course at the cost of trade-off.
2
Tests are just programs that run test cases. Some test frameworks have a separate test runner that can discover and execute all test cases. How that works depends a lot on the programming language. Sometimes the test runner is integrated in an IDE.
Integration tests are more likely to be standalone programs that runs the System Under Test. Often, ...
2
There is nothing here to test.
The point of a test is to help you read code. That is, to understand what it does and, more importantly, what it was meant to do. The only thing shown here is a bunch of things that need to be called. That's trivially obvious and tells us nothing about intent.
If the method had a good name or even a comment that made the ...
1
I am not fluent in Clojure, but why not pass the function for finding the parent path as a parameter to find-config-path, where .getParentFile is used as default value? Something along the lines of
(defn find-config-path
([path] (find-config-path path .getParentFile))
([path gpf] (cond (has-config? path) path
(= "/" path) (throw (...
1
Which way you find more readable, the pytruth ot the pytest way propably comes down to what you are used to. If you are used ot Java, you will find that more readable.
It is shared with the community to bring an expressive, consistent assertion style to projects that may be using a combination of unittest, abseil, googletest, mox, and mock—especially to ...
1
I would apply a single rule: keep your test data close to your test. Test is all about maintenance: they should be designed with maintenance in mind, hence, keep it simple.
Test data can be both input (context) and output (expected result) . Close to tests would be
directly into the test file (as an object defined in a variable or directly into the test ...
1
I think you are confusing Unit/Integration tests with mocking.
A unit test runs on real classes. The dependencies can be "real world" classes or fake instances - it depends on how you write the tests.
For mocking classes you can use external libraries like Moq or NSubstitute. Or you can use real classes.
The concept of "unit" test is about what you are ...
Only top voted, non community-wiki answers of a minimum length are eligible
