8
Open Source works best when there is a community behind the code. That means getting people interested in it. I would do a pre-alpha release and be really clear about the state of things. I.e. what you are confident in, what you are not confident in. Attempt to get people to start helping in the community.
As you build out the test suite (hopefully with ...
5
No, it is not a good approach. It is actually a terrible and common one. I would say it is a testing anti-pattern.
End-to-End tests like you describe are high-effort, low-value and have high risk of breaking when making code changes. The main issue here is that lots of software has it's tests written after the coding is complete, and adding stable and fast ...
2
You don't need a specific unit testing framework for this. We implemented such kind of automated tests using file comparisons against an "expected file" in several different variants utilizing NUnit (but it works with any other unit testing framework as well).
Though such a functionality could theoretically be provided by the framework, to my experience, ...
2
End-To-End tests have the following benefits
They are very close to what the end user sees (often they directly test what the end user sees). They can directly test the fitness for purpose for the product user.
They test thousands of lines of code per test
They test the environment the product is deployed into
So they do a couple things unit tests can't do,...
2
Given what you said, what I'd do is probably to send an interrupt (Ctrl+C) when the program hangs. I don't know about C#, bit in many of the languages I've used, this would raise an exception and an uncaught exception would normally end up with printing stack trace, which would give you a hint in where the code was blocking before the interrupt. If the code ...
2
It is correct that the test result depends on the "real" ApplicationService class if you use it in the test. That's exactly the problem that mocks are trying to solve.
If mocking creates brittle tests that need to be changed all the time, you are using mocks in the wrong places. In your example, the opposite statement is true: When using a mock, the test ...
2
I believe you should look at Technology adoption life cycle:
For you, the innovators and early adopters are the most important groups.
Innovators are tinkerers. They play and try things. They don't care about things working, as they are often willing to fix the problems themselves. They are willing to take on risks of things not working on themselves. For ...
1
it's 1 -> 2 -> 3 -> 4 -> 1 and thus on and on in a vicious cycle
It's not a vicious cycle. It has a very clear starting point: you wrote the code.
If you wrote the code, then it stands to reason you understood its purpose. If you understand its purpose, then you can write tests.
Testing is nothing more than checking to see if the written code fulfills the ...
1
If you use a mother (fixture factory) to handle the creation of an authorized and unauthorized user ? Then it would be centralized in one place for your tests and there is no coupling I believe.
https://martinfowler.com/articles/mocksArentStubs.html
The mock is more coupled because in this kind of situation we tell the test how the logic is performed ...
1
What is mocking?
Mocking is the process of replacing classes which our subject-under-test depends on with implementations suitable for testing
When is mocking successful?
Mocking is successful when we can say we have created a test with minimal cost that effectively tests the subject-under-test
Corollary
We need to be very clear what the subject-under-...
1
IMHO it's perfectly fine to make whatever calls you need to prepare your test pre-requisite conditions - they are necessary to run your test.
If your testing framework has test skipping capabilities and if you have ways to check if those calls failed - i.e. if your test's pre-requisite conditions are NOT met then I'd also recommend skipping the test - you ...
1
Spring is not needed.
You can create your tests with JUnit (As example) or another framework that let you mock elements. You only need to prepare your code to be tested. Maybe using JUnit inyection with annotations, parametrized constructor or setters to your class attributes.
Only top voted, non community-wiki answers of a minimum length are eligible
