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 2 years ago.
Improve this question
What is the best, preferably free/open source tool for auto-generating Java unit-tests? I know, the unit-tests cannot really serve the same purpose as normal TDD Unit-Tests which document and drive the design of the system. However auto-generated unit-tests can be useful if you have a huge legacy codebase and want to know whether the changes you are required to make will have unwanted, obscure side-effects.
Not free. Not opensource. But I have found AgitarOne Agitator (http://www.agitar.com/solutions/products/agitarone.html) to be REALLY good for automatically generating unit tests AND looking for unwanted obscure side effects
It is interesting, but such generated unit tests can actually be useful. If you're working on a legacy application, it will be often hard to write correct, state-of-the-art unit tests.
Such generated tests (if you have a way of generating them of course) can then make sure that behavior of code stays intact during your changes, which then can help you refactor the code and write better tests.
Now about generating itself. I don't know about any magic tool, but you may want to search for JUnit functionality about including some tests in javadocs for methods. This would allow you to write some simple tests. And yes, it's actually of some value.
Second, you can just write "big" tests by hand. Of course, these wouldn't be unit tests per se (no isolation, potential side-effects, etc), but could be good first step. Especially if you have little time and a legacy application.
Bonus Tip! There is an excellent book "Working effectively with legacy code" with examples in Java, including techniques right to use in such situations. Unfortunately you would have to do some things manually, but you would have to do that at some step anyway.
To be honest, I probably wouldn't do this. Unit tests are isolated and you won't actually know if you have "unwanted, obscure side-effects" because everything is walled off from the other things that cause the side effects. As a result, you need integration or system testing and that is not something you can automate.
Build a few high-level, end-to-end system tests which give you a degree of confidence and then use coverage testing to find out what you've missed, The downside is that when bugs crop up, it will be harder to point to their exact cause, but the upside is that you'll be far more likely to see the bugs.
Once you find bugs, write unit tests just for them. As you move forward, you can use TDD for the bits you want to refactor.
I know this probably wasn't the answer you want to hear, but I've been testing for many, many years and this is a solid approach (though I would hardly call it the only approach :)
Coview plugin for Eclipse (http://www.codign.com/products.html) looks just the job. I'm interested in generating tests that cover all the paths in the code, and this seems to do it. It also generates the mocks which should save me tons of time.
Diffblue Cover is a product that does this, and there is a free Community Edition that's an IntelliJ plugin, here: https://www.diffblue.com/community-edition/download/
It works by using reinforcement learning to search the space of potentially useful tests, and strives to write human-like tests. It automatically creates mocks and has full Spring/SpringBoot support.
Here's an example test for the owner controller in Spring PetClinic that it wrote:
#Test
public void testInitUpdateOwnerForm() throws Exception {
// Arrange
Owner owner = new Owner();
owner.setLastName("Doe");
owner.setId(1);
owner.setCity("Oxford");
owner.setPetsInternal(new HashSet<Pet>());
owner.setAddress("42 Main St");
owner.setFirstName("Jane");
owner.setTelephone("4105551212");
when(this.ownerRepository.findById((Integer) any())).thenReturn(owner);
MockHttpServletRequestBuilder requestBuilder = MockMvcRequestBuilders.get("/owners/{ownerId}/edit", 123456789);
// Act and Assert
MockMvcBuilders.standaloneSetup(this.ownerController)
.build()
.perform(requestBuilder)
.andExpect(MockMvcResultMatchers.status().isOk())
.andExpect(MockMvcResultMatchers.model().size(1))
.andExpect(MockMvcResultMatchers.model().attributeExists("owner"))
.andExpect(MockMvcResultMatchers.view().name("owners/createOrUpdateOwnerForm"))
.andExpect(MockMvcResultMatchers.forwardedUrl("owners/createOrUpdateOwnerForm"));
}
Related
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 2 years ago.
Improve this question
Our company is trying to adopt UI test automation. They showed me their previous attempt on Test Automation which was basically what you can expect from over worked QA engineers who are asked to create a test automation project alongside their other duties in short frame of time. From what i saw it had many flaws and wasn't successful. I am beginner in this field and i would like to find out about,
Any detailed guide of best practices in UI Test Automation
Any github repo for test automation project done by some
respectable company in software development showcasing best practices.
The reason i am posting here is that most of the guides i found online was basic or lacking details. Also it's impossible to find test automation project done by some software company. If any of you guys work in a company which has public repo kindly share it here that would be mighty helpful.
You probably aren't finding stuff online because typically those framework materials represent time and investment. They're either sell-able material (e.g. consultancies that have generic frameworks) or bespoke for a client (which e.g. expose internal system workings).
An automation framework starts with some requirements gathering. Loads of things to consider - Some sample thoughts:
Do you know what you want to test?
Is it purely web? Is it thick client? does it involve mobile? a mix and match?
Are you involved with the dev team? do you know what's been tested at the different levels before you get to the UI?
Do you have the right skills to follow this through?
If you google "automation framework requirements" you'll get a lot of ideas.
This article [disclaimer! - i wrote it] talks about automation problems you encounter from the top level without into the code. I'd consider most of those pretty good practice and there are parts of it you can plan for early on.
Taking a bit from the article:
Automation needs to test the right things
Automation needs to just run
Automation needs to run well
It uses examples from my career of things I've seen done wrong and how to correct them.
Beyond that....
Modern automation typically steers you towards the test automation pyramid (not my article this time).
When you get to the lower level, general programming rules are important. I can't give you a direct steer on a framework you've not designed but simple rules help:
DRY
YAGNI
SOLID (as much as you can)
Final thought here is you don't have to build a framework.There are generic open source frameworks out there which can get you started.
Make sure that application is in Regression stage
Automating and stabilizing tests take a lot of time
Don't try to automate everything in the beginning. Automate the most important tests. Flows which are followed by most of the people on the Website.
Decide the framework - data-driven or hybrid or POM
The decision of which framework to use saves a lot of time in the future. Data-driven is most simple and easy to change as well. POM and hybrid are complex but can be more reusable.
Look and understand some existing automation frameworks before you choose a new one.
Decide on the type of reporting you to need
Using Selenium for automated testing is a learning curve. It’s not as simple as copying from a working example. This is an article on Selenium automation testing to help you get started with learning the best practices. When beginning your journey with Selenium, identify a small UI feature to automate so you can familiarise yourself with the setup of required components, and how to run and manage the test. Try start with testing something like a login process, after which you can create more tests that incorporate more UI functionality once you fully understand the whole Selenium/Java environment.
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 7 years ago.
Improve this question
Are having APIs for the sake of QA testing a good or bad idea?
We're developing an application from scratch and we've been creating backdoor APIs to ease the jobs for the QAs. These backdoors do things many things like change the date of the server to emulate progression of time etc. I'm quite mixed on this. The number of these backdoors almost rival the real APIs that'll be used in Production.
Is this the recommended approach? The obvious benefit for this is that it makes the lives of the QA must easier. I can see many disadvantages with this also like maintaining the functionality of these test APIs, ensuring that these backdoor APIs are not exposed in production.
If others have used this approach, what are some good means to ensure that these APIs aren't exposed in production?
For those who are against this approach, are there alternatives to making the work for QA easier?
Thanks
If it's not causing QA to miss issues, it's a good thing to do; if you can make their job easier without costs in the future, do it.
However, normally anytime you test one API but use another API, you're not actually testing the real API that's going into production. If QA has a hack around the normal API, they should also be testing the difference between the hack and the real world.
In this case, it sounds like they have helper methods to modify the state, to enable testing. If there's not a good way to do this otherwise, what they're doing might be pretty darn reasonable... or, at the very least, there may be better ways to spend your time improving things.
But overall; is it regularly (repeatedly) causing them to miss bugs they should have caught?
What build system are you using?
For any software that has any time/scheduling logic, I think it's pretty essential to add a class called SystemClock with a method called 'currentTime().'
In our Android project, we inject the starting time from a Gradle variable, and then we can be sure that there is no way the code can get into production with shifted time (because the variable is defined for the debug build only).
For our iOS release, we were able to use an Extension. That's really a great way to do it because it's only compiled into the test scope. Then it replaces the getCurrentTime method with the shifted one.
The other option you have in the Java world is Aspects. They can be handy for doing mixins in a test build that are not there in production.
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 8 years ago.
Improve this question
We're developing a data heavy modular web application stack with java but have little expert knowledge concerning tests. What we currently do is using JUnit to run a mixture of unit tests and functional tests. I described the problem in more detail here.
Now we decided to set up standards early on, on how to test our modules and applications so we'll need to read up on the principles and best practices of testing in general and in the java spring environment in particular.
What I'd like to have covered are the definitions, use cases and reasoning behind the different kinds of tests from unit test to scenario test, or as google calls them: small, medium, large tests. Like I said, we're developing a data heavy web application.
I'd like to be able to deduce from the book how necessary and how useful each testing stage is on which corresponding level of our application (core, database access, security module, entity managers, web-model, web-controller, web-view)
It would be nice if the examples in the book are directly applicable to our application stack. We're using spring, JPA(hibernate), JSF, spring security. For testing so far we're using the basic Junit and some powermock. So JBOSS, Seam or Java Enterprise books are not so usefull.
If there are great articles on the web that paint a clear picture and really do help, feel free to share those as well (I can use google, SO and wiki myself, so please only articles that you actually read and deem very helpful), but a book would be nice so I can read up from the basics and don't have to piece it all together from various articles and questions.
Thanks!
Edit - books we ordered
Just started reading Growing object oriented software guided by tests and I already like it a lot. Not for the total beginner but shows how to develop test driven with agile techniques. Really cleans up old ways of thinking about software development.
We also ordered xUnit Test Patterns: Refactoring Test Code to get an idea of how to best unit test the different areas in our application stack. Got this recomendation twice so I'm hopeful it will be helpful.
Take a look at the resources under this answer. I highly recommend the first three books, the first two directly address your "levels" questions. The first is more focused on specific tools, while the second is more conceptual.
Book recommendation: JUnit Recipes - Practical Methods for Programmer Testing
Tools: JUnit + Hamcrest + Mockito
And you're using Spring, check out spring-test, it offers some great facilites, Spring Testing
Hate to give you a snippet of an answer (as you've said you want a solid guide) but I can't really recomment any books. Best practices should involve TDD though. It's much bandied about but it aids regression and eases the mind when those ad-hoc quick requirement changes come in (when you know you've a solid codebase).
Additionally, you may want to see if BDD (Bean Driven Development) is right for you. I mention this as you may not stumble upon it in your searching. Advantages include translation from English to test cases to prove test scenarios in terms of goals. This allows you, your testers and even your product owner to easily correlate the tests with your requirements:
See easyB
SpringBeans in easyB
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 would like to know which tool is best for finding any kind of bugs in my code. I know this may be some what theoretical or never ending question so I would like to modify it in terms of the efficiency of bug reporting (including the naming convention as well). So you can say which tool reports and maximum bugs and if effectively used in the industry? I heard about findbug is it really good?
FindBugs is probably one of the most prominent ones and well worth a try.
For naming conventions etc, I'd suggest you have a look at CheckStyle.
Findbugs is quite good. However, I would recommend using sonar to maintain code quality. http://www.sonarsource.org/
It integrates well with maven (sonar:sonar). Other than this I believe the use of maven site to create checkstyle, pmd, findbugs et-all report also helps keep the developers on toes.
It depends on what you are looking for. Personally, I use a combination of FindBugs and PMD for performing static analysis of Java code. However, I recently discovered an Eclipse plugin called CodePro Analytix by Google.
There are two types of analysis for Java code - source code analysis and byte code analysis. PMD looks at the source code to find possible bugs, unused code, suboptimal code, complicated expressions, and duplicated code. FindBugs looks at the generated byte code to find possible errors. Both are essential when analyzing an application.
However, when it comes to finding defects, nothing beats a good testing framework and (if necessary) a mocking library. I've had good successes with JUnit and Mockito. This will enable you to write unit tests for your modules. Writing code system, integration, and smoke tests, either using automated tools or test procedures is also important so that you can cover core functionality and quickly see when something is broken.
I prefer to use the Code Analysis in IntelliJ. It not only finds many probable bugs and improvement but has quick fixes for a lot them which makes it practical to fix large amounts of code.
use a compiler to find syntax 'bugs'
use test cases to find usability 'bugs'
use test harnesses in the code to find regression issues with code modifications.
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 3 years ago.
Improve this question
in private and in companies it is over and over again a problem that I or we developers comment in fact our code but generally nobody knows exactly how the code of the whole project works together. When I write my own code and the project is getting bigger I sometimes have this problem too. Although I write tons of comments, after 3 months you don't know what the whole thing exactly does, that means how the different methods and classes work together.
How do you solve this in your company or in private (if there is just marginal project development and no requirements specification). Or do you have always such a good project development with contract document and requirements specification that you don't have to worry about that?
Code complete can explain the solution to your problem better than I ever could.
I find the best way to solve this is to write a functional test using a unit test framework.
In a functional test you write a test which loads up several if not all the core components laid bare. This shows that all the components work correctly together but also you get a documents which shows you in one place how everything connects.
Depending on how complex you interactions are, you may not be enough and you need to document it. Personally I would prefer to make the code simple so that documenting it is not really needed or is relatively easy to explain.
If documenting it sounds too hard, its time to refactor your code so that its not.
Take your time a create some short and simple design documents, add some UML diagrams to just show the basic ideas behind the whole application. This would give new team players a quick overview. Publish this documentation on an internal wiki and encourage the team to enhance, if necessary.
Then, as Peter suggested, some well documented test cases really help: Read the test code and learn how to use the API. (and, as a secondary effect, test the code ;-) )
I would not put too much effort on comments, especially on line comments. The tend to become out dated, because no unit test verifies that line comments are still valid and, even worth, no one ever deletes unnecessary comments.
Good question. Part of what you are asking relates to code maintainability. In my view the two main things you can do to improve this are:-
Write some design documentation
Develop maintainable and clearly written code
From past experience the first item is very often neglected on software projects due to time constraints, but I think that if you can produce at least a class diagram of your system, then this is worth a lot in terms of understanding how objects interract when you revisit the code in a few months. Depending on the complexity, then sequence diagrams can also be useful. Producing this documentation will also be of benefit to new members of the team, in quickly having an overview of how the software is structured.
I can't stress enough the importance of writing clear and maintainable code. My eyes were recently opened when I read Clean Code by Robert Martin. You owe it to yourself and your fellow developers to read at least the first couple of chapters in this book. That alone will immediately improve the readability and maintainability of your code.
The idea is that the code should read almost like a narrative, where methods follow in a logical order, are short, appropriately named, and take few parameters. Doing this almost eliminates the need for code comments, and improves the code structure.