Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a Rust project that has several modules. I've been adding a module called tests where I put my unit tests but I've gotten to the point where testing needs a significant amount of scaffolding and I believe that will add a lot of noise to the code base. Is there a way to move my tests elsewhere, perhaps to a tests.rs file?
Cargo supports running tests from tests/ subdirectory. You can find a reference to this (though rather brief) in the Cargo guide. In short, you can separate tests from your main source tree by placing them in sources in tests/ subdirectory of your project. These tests are just normal Rust sources (with #[test] annotations), so you need to extern crate your crates to test them there. This supports writing integration tests, not unit tests.
Unit tests are usually written in #[cfg(test)]-marked submodules of the module under test. They are able to access non-public items of their enclosing modules, so this is ideal for unit testing.
There is also a recent change in Cargo which allows something even more powerful, but I'm not sure how it should be used exactly.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Kind of a meta question, but I was wondering if there would ever be cases where writing a unit test for a unit test would make sense.
You don't have to write a test for that, generally its considered Mutation Testing.
Mutation Testing is a type of software testing in which certain statements of the source code are changed/mutated to check if the test cases are able to find errors in source code. The goal of Mutation Testing is ensuring the quality of test cases in terms of robustness that it should fail the mutated source code.
From Guru99
There's a few well known examples,
PIT for Java
MytPy for Python
Stryker looks like its the one for Javascript.
You could write you own tests that mutate your code itself, but its sensible to use OSS projects and help contribute to them if theres any unique needs given the complexity of the area. You don't want to have to own your own mutating framework either and all the maintance with that.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
Should you include testing external dependencies in your unit-tests, eg. not mocking the objects in the dependency but actually creating an instance in your unit-test as to ensure some third party didn't do something stupid like creating a BC-break in a patch release. If so, how do you do this? I can assume that automatically instantiating external code could lead to serious security vulnerabilities.
So after some great comments from #Nkosi I have come to the conclusion that this should not be a part of your unit-test suite. However to correctly test against deficiencies in external dependencies, integration tests should be set-up.
While looking into integration testing I came across a great answer about the balance between unit-tests and integration tests on StackExchange: https://softwareengineering.stackexchange.com/questions/208458/when-should-i-write-integration-tests#answer-208465
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I recently had an argument with my supervisor about unit testing. My office is currently working on DRs for an upcoming release and he has created a DR process. One of the steps is to develop a unit test for your DR. This is where we differ greatly in opinion. He told me that this test is performed through the user interface and that the difference between functional and unit testing is that unit tests are more localized. I am of the opinion that a unit test has to be code based because it should only test a single part of the code and this is the only way to isolate it. I also said that unit tests were almost exclusively done in frameworks (such as jUnit) for every part of development e.g. development or maintenance. I would like some people to weigh in on this. Can unit testing be done through the user interface of an application? What is the most common way to achieve unit testing?
*Note: Yes, I did google it but most of what I found was vague enough to accommodate both of our conflicting ideas. I am looking for more real world answers. Thanks for your time.
He's wrong. A unit test is a unit test because it isolates dependencies and tests a single aspect of your code. A test that runs through your user interface isn't a unit test simply because even displaying the UI involves dozens of dependent interactions, none of which you can isolate or control for the duration of your test.
Testing frameworks are irrelevant. You can be using a "unit testing" framework and still write something that's not a unit test. For example, you write a test that writes a file to the file system, and you assert that the file exists. Well, your file system is a dependency that you didn't isolate. You wrote an integration test, not a unit test.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am currently at about the 50% point in a web app's development, getting to this point by rapidly coding followed by refactoring. After reviewing with the client again at this point, the scope of the project required for completion is clear and unlikely to change.
Is it advised at this point to start implementing tests? If so, do I create tests for the functionality already completed or prioritize TDD for the remaining parts of the application?
As mentioned in the comment by #zerkms it is usually advisable to use TDD for new functionality, and when you change existing behaviour.
To guard the functionality you currently have, use some integration tests and smoke tests for some typical, and crucial scenarios. Don't aim to achieve high coverage with these tests, as it will be to much of a burden to maintain them in the future. If you will be persistent at writing unit tests for discovered bugs and new stuff in time you will get high coverage.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
How can I unit test a JSP? I want to ensure there are no tag misspellings, etc.
I am already aware of the HtmlUnit/HttpUnit/JWebUnit/Selenium possibilities for System testing. I want more of a unit test.
I would say that testing a web app (be it JSP or other) using its web interface, with one of the above mentioned frameworks is not unit testing in the strict sense. Unit testing means testing small parts of your app (one method, one class) in isolation. With a web framework, you test the web app as a whole, so this is more like system or integration test. Which is not to say it is not useful - on the contrary - just it is better to clarify terminology.
Having said that, if I were to test a JSP, I would most likely be satisfied with a system test of all specific scenarios associated with the JSP, using some of the tools mentioned above.
However, if you really want "classic" unit tests, I guess the closest you can get is compiling your JSP into a servlet class, then calling the servlet methods directly (from e.g. JUnit, using a mocking framework like EasyMock to prepare the Http request, response etc. objects).
Update: IMO the only reason to need unit tests for a JSP is if you have business logic in it. Which, in turn, goes against the separation of UI and business layer. So it is better to redesign the app and move the logic into a separate POJO (if you have the choice) than try to write contrived unit tests in order to test business logic where it doesn't belong.