单元测试与集成测试及其维护

Question

I am working on a web application which is constantly enhancing in parallel development environment(develop two requirements in two different environments and merge first code base to second, when first requirement is released to production).

My question is about having both integrating testing and unit testing for app and its maintenance.

Unit testing with mocking makes difficult to maintain tests in parallel development, integration testing(using selenium) in parallel development makes difficult to maintain required data in database(which may be easy than fixing a failed unit test)

I am leaning towards integration testing, as merging code will not break use case, but unit test case may fail by merging code because of expectations. The app is little old and not properly designed For unit Testing and refactoring code and maintaining unit test cases is becoming hard.Please suggest a better approach for testing.

Answer 1

Unit tests and integration tests both have their place. Unit tests, as the name indicates, verifies the unit is behaving as expected. It's true that integration tests cover the same code that is covered by the unit tests. But unit tests help you pin point issues more easily. Instead of investigating the failure to understand which part of the system is responsible for the issue - you have a failing unit test to help you find out. Another reason to have unit tests is speed. Unit tests should be fast. They should not rely on various system dependencies (you should be using mocks and stubs for that). If you have unit tests with good coverage you get feedback fast regarding the quality of the system - before you start your long test cycle.

Actually you usually employ various level of automated tests:

1. Smoke tests. This are unit tests that test various part of the system in the most basic scenarios. They are usually employed as part of a gated check-in that don't check in bad code. You need this to be fast.
2. Regression - unit tests. Usually part of continuous integration. Again you need this to be as fast as possible so that the build will not take too long.
3. Full regression + integration tests. These are more system tests that take longer to run. These usually run once a day in a nightly build or even less frequently (depending on length)

Answer 2

If you find the cost of maintaining some types of tests too high, it's sensible to consider dropping them. I think integration tests are more important for QA, and if I could only choose one type of testing (unit vs integration) that's what I would go with.

However, first you might also want to consider if there is a way to factor your unit tests to avoid these maintenance issues. When I first started using mocks, it took me a while to find the right balance. In my experience I find it best to avoid mocks (with expectations) as much as much as possible. I do use mocking libraries, though, just mostly for trivial stubbing rather than more complex mocking. I wrote a blog post about this a while back if you are interested.

Answer 3

W/ regard to the unit test issue:

I would suspect that the unit tests you are constantly having to refactor are a bit too low of a level. Generally it is better to have somewhat higher level tests that exercise the lower level code by varying the inputs.

Assuming there is not unnecessary code, the higher level tests should still provide good code coverage (if they can't reach code, why is the code there?).

W/ regard to the functional test issue:

You may want to consider a representative data sample (or several). That way you can have a known input, so you should be get predictable output.

Answer 4

Avoid unit testing altogether. Or start with Unit testing and once you reach integration tests "pass the relay baton" to integration testing. Delete the unit tests previously written or leave some for documentation.

1. Code coverage cannot be measured with integration testing(as it passes through different systems.)
2. Eventhough mainiting both unit tests and integration tests are ideal theoretically let us not risk it says the experienced.
3. Only an advanced unit tester can become integration tester. So only those who have become integration testers can advice against unit testing. We better listen to them because they are passionate about unit testing and are willing to sacrificing the 'fun' of writing unit tests for better 'safety.net' for the team.
4. Integration tests are difficult to implement (seeding DB, infra recreation,etc) and we simply wont have time to maintain both(unit and intgration tests)
5. Unit testing can still be good for library(.dll), framework development, complex calculations and also for product development companies. But how many of us work on these? These days for web develoment, everyone can work in end-to-end scenarious easily as there are frameworks already available. For this integration tests are best anyways.

Some helpful links:

"Why You Need to Stop Writing Unit Tests" https://hackernoon.com/why-you-need-to-stop-writing-unit-tests

"Write tests. Not too many. Mostly integration." https://kentcdodds.com/blog/write-tests

"The No. 1 unit testing best practice: Stop doing it" https://techbeacon.com/app-dev-testing/no-1-unit-testing-best-practice-stop-doing-it

"Unit test kills" https://www.linkedin.com/pulse/before-you-feed-unit-test-beast-sanj-ay-mohan/?trackingId=5eIFIJGSBpnGuXMEz2PnwQ%3D%3D