3 ms·

To answer you question it really depends what kind of projects do you have in mind and the organisation structure and the market. Outside academic world, testi

by gls2ro 5y ago

To answer you question it really depends what kind of projects do you have in mind and the organisation structure and the market. Outside academic world, testing (part of software development lifecycle) depends on the type of projects, the organisational structure and the market. It it is influenced a lot by company quality definition (even if not defined properly, informal) which is highly correlated with market expectations about quality. Of course one can choose to follow some testing principles and apply them everywhere, but I think a testing strategy should be chosen first based on project needs and then based on knowledge of the developers. Just to give some examples: For example if you work in web design for a consultancy it might be that you will focus on a niche so probably the projects will look similar. In this case unit tests should not be different between projects, except when the client has different quality requirements or expectations. If you work for a product oriented company and lets say you have feature teams then probably unit tests will look similar between feature teams working on high level features but different than for the teams working on performance oriented or low level features. If you switch companies then I think unit testing might look different as they approach software development (and so testing) and market differently, by focusing on different attributes/decisions that they think will give them leverage. Also, in the specific case you mention (mockist vs classicist) I see a difference of the outcome of testing when applying one or the other on testing pure functions vs impure functions. Why do you consider this distinction as being fundamental on how people approach unit testing? And - just out of curiosity - what do you think is the difference between mockist and classicist?

WolfOliver 5y ago
When a test in the classicist style fail (maybe because you refactored something), it tells you something is not working with your actual software but you do not see directly where the error is. You only have to fix the software, your test most probably still works. This is because you did not test implementation details but only the "what" should be done. When a test in the mockist style fail, you see directly what part of the system is broken. But the rest of the day you are bussy fixing your test suite as the test are tightly coupled to the "how" something is done.
- WolfOliver 5y ago
  So classicist try to write the test that they do not break when you change the implementation (e.g refactoring) Mockist don't care so much about this, they focus on isolating the unit. Interesting fact: Originally unit tests are called unit tests because they can be executed independently from any other tests. Not because they test a single unit.

by gls2ro 5y ago

WolfOliver 5y ago

When a test in the classicist style fail (maybe because you refactored something), it tells you something is not working with your actual software but you do not see directly where the error is. You only have to fix the software, your test most probably still works. This is because you did not test implementation details but only the "what" should be done. When a test in the mockist style fail, you see directly what part of the system is broken. But the rest of the day you are bussy fixing your test suite as the test are tightly coupled to the "how" something is done.

WolfOliver 5y ago
So classicist try to write the test that they do not break when you change the implementation (e.g refactoring) Mockist don't care so much about this, they focus on isolating the unit. Interesting fact: Originally unit tests are called unit tests because they can be executed independently from any other tests. Not because they test a single unit.