Is restfuse dead? #63
Comments
|
i think we (the contributors) should pickup this where it left off. This is ONE of a KIND project, and if you try to look for a REST testing framework, you would not find ANY that is reasonably good and Free |
|
HTML Unit. I lost patience with Restfuse as it was buggy and didn't do everything it said it should. html unit has been very nice so far. i think we (the contributors) should pickup this where it left off. This is ONE of a KIND project, and if you try to look for a REST testing framework, you would not find ANY that is reasonably good and Free— |
|
I looked at Restfuse, saw comments similar to those in this thread and decided to use RestAssured instead. I like the programming model of Restfuse ... it's so much better than the (Ruby like?) DSL you use in RestAssured. I do like that the DSL includes methods to test the response contents including parsing JSON structures (I can add JSONUnit to Restfuse and get the same functionality). In any case, I'd be happy to pitch in and help with the Restfuse project IF the current maintainer will let someone take it over. |
|
Sent an email to Holger Staudacher , asking his permission, but i personally would think it would be ok to start at least fixing the build and work on the bugs. As for RestAssured, i did look at it while evaluating a REST testing framework, and it has the disadvantage of Groovy being used, which is yet another language to learn and increases the pre-requisite knowledge in order to use the framework |
|
I have started working on the bugs , and once i get a bit deeper understanding of restfuse, i will perhaps contribute to enhancements. My question is: what is the best way to maintain restfuse.
how to use GitHub effectively for your project GitHub provide an awesome set of tools for opensource developers. For Dancer, we use them as much as possible. I'll show and explain how we do our development. code review Dancer's development goes fast. We do our best to ship often, we do a lot of refactoring, and we listen our users. This means processing pull request and issues as fast as possible. There is five developers with write access to the main repository. Each one is asked to do a review of pending pull request every morning (this is not required, neither enforced, it's a "if you have ten minutes in the morning while drinking your cofee, please, review the PR"). When we're reviewing something, most of the time we pull the submited patches into a branch named review/username. If the reviewer is happy with the modifications, he will add a comment to the pull request: "approved" (and some other comments if it's required). In case he's not happy, he will comment disaproved and give his reasons (tests doesn't passes, or there is no tests for the patch provided, or this is not something we want, etc). If the PR is about something the developer doesn't really knows, or has a doubt, he skip this one, and ask for someone else to take a look. In order to merge the branch review/username, we need two developers to comment approved. Of course, for something simple, like a documentation fix, or changing a few line somewhere, we can merge this without applying this process. As the work consists to read the code and comment, it's quiete easy to handle two/three pull request each day for a developer. When one of the developper with access to the repository find some time, he can go through the pull request, and merge the one marqued as approved, since he knows that the people who had already approved them understand the code. We don't use RT to manage our issues. It's not that RT is bad or that we don't like it, it's just that GitHub's issues are more integrated with our workflow. GitHub's issues are really simple (one can even say naive), but most of the time it's ok for our usage. We don't need advanced features like "track how much time you've spend on this ticket" (even if I do track my time spent on Dancer, using orgmode). One of the nice feature of GitHub's issues, is that you can close them with a commit. If the commit's message looks like 'closes GH-123', the issue 123 will be closed, with a link to the commit in the comment (take a look). I find this feature really useful, since when refering to a closed issue, you can find the commit inside the ticket. Once or twice a week, we try to proceed a triage, where we go through the issues, and tag them. When someone report something on the mailing list or on irc, we ask them if they can open an issue, since it's easier for us to track the request. An issue doesn't need to be about a bug, it could be: commenting on code Another nice feature is the possibility to comment the code. Most of the time you'll do it while reviewing a pull request. But a user can also comment on something. Sometimes we push a branch that need some feedback, and a discussion will be started. You can easily diff two branches. With this url you can do a quick diff of the changes between master and devel, see the list of commits, and which files have changed. This is usefull when you want to have an overview of the work. We're using gitflow to work. Gitflow is a nice tool that help you creating and merging branches. If you don't know gitflow, there is a good article that explain the reasons behind it. Ok, this has nothing to do with GitHub, but I'll explain quickly what we do with it. an article on gitflow: http://scottchacon.com/2011/08/31/github-flow.html We use the following conventions: It's very rare that we need to push a hotfix or release branch to GitHub: thoses branches had a really short life span. But topic branches can be pushed, when we want feedback from users or other developers. We're already using jitterbug to do some continuous integration. When we push to GitHub, a payload is posted to jitterbug, and a build is triggered. In a near future, we will use git's notes with jitterbug. The idea is to store inside a note, for each build, the duration of the build, and the result of the build (failure / success) and maybe the TAP output in case of a failure. This will allow developers to see directly in the logs the status. Of course, GiHub already display them, so this will be very useful for all of us. lumberjaph.net is © 2008 – 2014 Franck Cuny // @franckcuny references: |
|
+1 for option "1. Fork it, and THEN Enhance it." |
|
@GGBeer I came here to play devil's advocate to your comment (+1 for option "1. Fork it, and THEN Enhance it."). Now that I've pulled the code and attempted to build and test it in a few different configurations, my opinion has changed dramatically. To be fair to the discussion, I'll include the pros I was originally going to promote:
I'll admit I'm a fan of more minimalist projects and therefore not a fan of some of the (what I consider) Maven bastardizations. The main point of Maven is "convention over configuration" and I think this project is a great example of what NOT to do:
I haven't tried analyzing the project with Sonar yet, but I'll give my impressions ... I think the code quality is actually pretty good, but there's an almost complete lack of comments in the classes I looked at. I spent a couple more hours carefully merging the existing pull requests into restfuse and while I'm not sure I understand all of the Tycho related cruft, it does seem to build the library. One integration test is failing as noted above. You can find the (hopefully temporary) project here: https://github.com/selesy/restfuse and a JAR file containing the results of my work here: https://github.com/selesy/restfuse/releases/tag/v1.2.1-SNAPSHOT For the most part, the example code works ... there are two TestCases with two tests each that fail:
If the group is so inclined, I'd be more than happy to delete the unnecessary build tools and set the project up so that it's built in a conventional Maven fashion. The only issues I have with doing so is whether we'd conform to the EPL license with a dramatically restructured project, and whether it's fair to the original developer(s). It's entirely possible either don't understand what they were trying to accomplish with OSGI/Tycho or they were working towards a bigger goal that isn't visible to the group. For posterity, here's the process I used to create v1.2.1-SNAPSHOT:
Sorry for posting such a long comment ... where should we go from here? |
|
Had the same problems with the directory structure and build tools. As I am currently not using Eclipse and are not that familiar with OSGi/Tycho/etc. I just created a new local maven pom.xml with a standard directory structure to get going, but copied my changes back into the original dir structure before commiting to my fork. Your pros are definitely true and we should respect the original project developers work and efforts. Also don't know if the EPL license model is still OK or should be changed. |
|
I have confirmed that the DynamicPathTest.java tests failed due to changes in search.maven.org and have modified the tests to expect a 302 HTTP status code (the latest is at: https://github.com/selesy/restfuse). I'm tempted to make a branch with the project moved into a conventional Maven project ... I think a parent project with one child module for the library and another for the examples would be enough. The test module could be moved into the library project under src/it/java and run with the maven-failsafe-plugin. I can provide CI and analysis via Sonar but I think before we get too far along we should make some decisions about project name (if it needs to change), how to update the documentation (especially developer documentation), etc. |
|
Thanks smoyer64 for taking over this great project. Any plans to update an artifact in maven repo? |
|
I started working on simplifying the project and believe it's back to I was waiting to hear what the group wanted to do long-term ... I feel as In any case, I'll be generating releases as I go but I'm not sure I can get On Fri, Feb 6, 2015 at 5:55 PM, yurgisbaykshtis [email protected]
Sent from my iBerry MacPhone |
|
smoyer64, The name would depend on what are we going with restfuse . Here are some which we can ammend, or augment.
|
|
Nice to hear that RestFuse is moving again. An addition pain is the use of dynamically generated paths. It can be achieved but is very cumbersome. Just to illustrate I will give you an example what I'm currently testing with REST fuse:
In this scenario the login call creates a cookie (session), which must be than provided on the next calls an so on. Currently the code is way to complicated for what it does. |
|
Unit tests are supposed to be idempotent ... the changes you're describing REST isn't supposed to rely on state being managed on the server and in the I think testing security is a very common use case and can be broadly I've used RestAssured and it's a lot more like what you describe ... the This should probably be a separate conversation ... I think there's a lot On Sun, Feb 8, 2015 at 6:42 AM, drejc [email protected] wrote:
Sent from my iBerry MacPhone |
|
Starting from junit 11 you can execute tests in name order. What we do is just prefixing names with test###_ (like test002_userPut). On Feb 8, 2015, at 3:42 AM, drejc <[email protected]mailto:[email protected]> wrote: Nice to hear that RestFuse is moving again. An addition pain is the use of dynamically generated paths. It can be achieved but is very cumbersome. Just to illustrate I will give you an example what I'm currently testing with REST fuse:
In this scenario the login call creates a cookie (session), which must be than provided on the next calls an so on. Currently the code is way to complicated for what it does. — |
|
Maybe this is one of those cases where it's best to work backwards ... On Sun, Feb 8, 2015 at 12:48 PM, yurgisbaykshtis [email protected]
Sent from my iBerry MacPhone |
|
Currently I am using RestFuse to test my JSON-based Webservices. For testing a specific WS-Function I have to make sure that all objects which are required for executing that function have been generated/added in advance and the TestCase must use/reference the specific UUIDs associated to these (temporary) objects. Also some parameters of the testcases must be generated on TC-execution e.g. include timestamps, provide unique object names, etc. The ordered testcase execution and DynamicBody features can be used for this but are difficult to use in large test scenarios. For that reason I extended RestFuse to have full control over the HTTP headers and body just before the message is sent out via HttpRequest. At that point also access to the HttpTest-Annotations was important to me for defining further test specifc parameters/details (e.g. the fields containing the UUIDs to be used). Via reflection an instance of a ProcessRequest-class (definable by an HttpTest annotation parameter) is created in the HttpStatement.evaluate() phase. This ProcessRequest class can do just anything to/with the HTTP contents at that point. Also via reflection the test specifc parameters are retrieved by their field getters. My restfuse changes are far from perfect and have lots of room for improvement, but maybe they are usefull to the community. Thx, |
|
Ok ... here is an example ... of a simple test of mine ... just for illustration purposes. @Rule
public Destination destination = getDestination();
// provide dynamic destination according to stored cookie
private static String authCookie;
private Destination getDestination() {
Destination destination = new Destination( this, TestSettings.HOST);
if (authCookie != null)
destination.getRequestContext().addHeader("Cookie", authCookie);
return destination;
}
@HttpTest(method = Method.POST,
path = "/rest/public/login",
content = LOGIN_JSON,
type = MediaType.APPLICATION_JSON,
order = 20)
public void login() {
// login user
assertEquals(HttpStatus.SC_OK, response.getStatus());
List<String> cookie = response.getHeaders().get("Set-Cookie");
// cookie is store in static variable ...
authCookie = cookie.get(0);
}
// not public ...
@HttpTest(method = Method.GET,
path = "/rest/user/info",
order = 30)
public void getInfo() {
assertEquals(HttpStatus.SC_OK, response.getStatus());
String body = response.getBody();
... assert response ...
}Current disadvantage is that @path, @content and @authentication can not be dynamically generated so you are kind of limited with the current implementation. While the static annotation principle is nice for simple tests ... the dynamic aspect should also be considered ... for instance a call to GET /test/user/info/{userId} is not possible at the moment. |
Please tell us what you plan to do with restfuse and where it will go. As of now, there seams to be no current commit nighter some other work happening. Also there are multiple long pending pull requests in this repo. Is restfuse dead or still alive? It is an interesting project and if it's still alive, I'm interested to contribute and add some new features.
The text was updated successfully, but these errors were encountered: