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.
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 5 years ago.
Improve this question
I came to know that in some shops, code is developed first, given to QA for testing and then developers write unit tests for that code. Is this approach acceptable ? If yes, then what are the pros & cons ?
I got some clues in answers in an unrelated question : Is Unit Testing worth the effort?
But, I also need answers specifically for my question.
A lot of serious dev "shops" do this.
When you develop complex applications for a client you never actually "care" about simple unit tests, the ones you can write any day of the coding project. You have to "test at a coarser level of granularity" (32:30 in the video) and you generally want to test things that are not supposed to change so you don't write tests over and over again, when the architecture changes a bit.
To answer your question: creating unit tests at the end is a fail safe for later, when you fix bugs making sure they don't break existing client required functionality. Writing tests at the end also gives you the insight you need to write them, the client's wishes are known and not subject to change any more.
Bottom line: It's not a science, you only get good at it while doing it.
PS: Not a fan, but this one is "right on the money" https://www.youtube.com/watch?v=9LfmrkyP81M
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 7 years ago.
Improve this question
Our project is in agile environment where requirements keep changing every sprint. The annoying part is the unit tests keep failing due to the requirement change. And now it takes longer to fix and maintain them.
Do you have any suggestions in general, what is the better approach for this situation? Thanks in advance.
This is a common issue, and is related to how committed you are to maintaining your unit tests.
You mention your tests break when requirements change, so I'm assuming this means you update code to meet the changing requirements, but you're not updating your tests at the same time.
A development approach fully committed to the benefits of repeatable unit tests would always update the unit test code at the same time code changes are made. If you don't, how do you re-test the code changes, or how can you prove the code changes work?
If you're not committed to maintaining unit tests at the same time as code changes, then you might as well embrace that fact and throw them away as soon as the code changes, because at that point, as you're finding out, the tests become useless.
It's a common problem and one that many projects struggle with. Are tests written one time to test code when initially written, but after that point are discarded, or are they always maintained at the same time when code changes are made? Sure, it adds more effort to maintain the tests, but then you benefit longer term from having a suite of repeatable tests that you can run at any time to test that your code is working as expected, before and after any code changes.
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 still read that without unit testing, you cannot be agile. While I understand the purpose of unit tests, why they are so crucial in agile? Is it because the frequent builds might easily brake something?
And what about integration testing in agile, is that the same case?
Thanks
"...without unit testing, you cannot be agile". Strictly speaking, that is a false statement. Agile doesn't prescribe a particular testing methodology. Anybody who tells you otherwise doesn't understand agile. Agile is about delivering high quality code and being able to respond to change. If you can do that without writing unit tests, you can still be agile.
That being said, unit tests are an important part of software development no matter what the methodology. It's difficult to write high quality software on a large scale without them. They help you determine that the individual units of your code are behaving the way they are designed. Whether you use unit tests, and how many unit tests you write, is a factor of how important it is that your code is correct, how hard it is to fix defects if they make it into production, and so on.
I would say that for most projects, having a robust, well-maintained set of unit and integration tests helps your team be more agile. Having a good set of unit tests is very liberating as a developer -- you are free to make changes more quickly because you have a safety net. This makes it easier to quickly develop stories and verify they are correct.
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.
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.