I recently starting learning test driven development, namely MXUnit, and I love the idea's behind it. I can understand the idea of using TDD with stand alone CFC's, but when it comes to using it with OOP based Frameworks, primarily FW/1 and CFWheels, I am not sure how to use MXUnit with the framework CFC's (controllers in FW/1 and Models and Controllers in CFWheels).
Does anyone know where I can find some resources on using MXUnit with Frameworks?
I can only talk about F/W 1 here as I have not used CFWheels (some info here in another SO question), but in my opinion framework unit testing can be simplified by proper use of a service layer.
The idea is you test service layer objects using MXUnit and leave the framework controllers (for example in FW/1) very lightweight. Essentially the controllers are just passing parameters to the service layer, getting a response back and displaying a view.
The reasoning is that the framework is the least likely place you'll introduce errors - so concentrate your testing on the service object, i.e. the core business logic of your application.
Interestingly, in other non-ColdFusion frameworks (such as Grails) the framework is not tested, tests are created for your model ('domain classes' in grails that model the data) and your service objects, but the framework is assumed to work fine. The idea there - again - is to keep logic out of your controllers and test your service layer and domain model.
I hope that helps in some way.
Related
Let's say I have a frontend application written in Angular and a backend application written in Django and Django Rest Framework. I created unit tests for backend application (with pytest) and I'm about to create some functional tests for the frontend application. The thing is that the frontend app needs access to the backend app in order to work correctly. I can write some mocks to handle that, but I am not sure if this is the best way to do that.
My question is, what is the best way to handle that? Should I use a single git repo for both applications or maybe a better way is to use two repositories, but then how to handle the tests for frontend application?
I was also thinking about using selenium with pytest, but then I would have to use a single repository. I am a little bit confused and would really use some good advice. Thanks!
Unit tests as the name suggests is testing separate units of the code in isolation. Meaning that it does not have to depend on any other part, else, you wouldn't know if the test is failing for that particular unit or the units it depends on.
As a result, all tests should mock the request to the backend and return valid responses (or invalid, if you're testing for error handling). The same applies to any other external service that the unit depends on.
for a front-end developer, who writes angular code, what part of a javascript front-end project should I be unit testing? I find it needless to test a lot of the code, and my biggest hang up is which part of the angular services needs to be tested? if $httpBackend is a mock call, what's the point of calling it?
As your project grows in complexity, you may find that your angular application is doing a lot. Angular's design allows the client to take a lot of the responsibility for processing and rendering data from the server.
Yes, I agree, you shouldn't test anything but your own code. So, writing tests for $http is useless. However, if you are expecting the server to return a specific JSON contract, and you want the assurance that you are mapping that correctly to a structure that you will use in your angular app, that is worth testing. Further, if you are making calculations in services or controllers, that logic is worth testing.
Angular itself is set up to support TDD because it has a nice separation of concerns between the view, controller and services (even directives can be compiled and tested). All of the javascript code that you write is a good candidate for test coverage. So, IMHO, you should be unit testing your directives, your controllers, and your services. You can get as detailed as you want to give yourself the assurance that your code is solid.
In web frameworks like ruby on rails, any database queries needed to handle a specific request happen before a page is passed to the client in a controller class, but there's nothing like that for clojure. Where should database queries and stuff like that be handled in a clojure web app? My gut tells me to call a function within a hiccup page and generate the HTML within that function, but I'm not really sure. Thank you for your time and consideration.
There aren't that many "full stack" web frameworks in Clojure and as far as I know most Clojure web applications aren't built with one. There is a collection of frameworks and tools that handle a variety of things, but you'll likely develop your application using these components as building blocks. You have a choice of routing functions, authentication, view rendering, templating, RESTful web services and persistence.
Where particular things should go in your application depends on your architecture - a typical, 3-tier MVC web application looks different from a full blown scalable app that's using CQRS, CEP and other fancy patterns that help you build the next Facebook or Twitter.
If you design your web app conceptually with a 3-tier MVC architecture in mind, you'll have a clear separation between your view layer, business logic, and persistence layer. Like Alex said in his answer - it's probably the Controller that ties these things together. If you don't have complex business logic, your controller will likely call functions from your persistence layer directly before passing it on to the logic that builds your views.
For some situations, it might be useful to pull in data from your persistence layer in a "middleware" — that is a function that gets called by Ring every time a request comes in. This could be the stored information about a logged in user for example.
A number of options for your building blocks: Mature Clojure web frameworks?
Most (all?) of Clojure's routing/request handling frameworks are built on top of Ring. An overview of what that looks like is here: http://brehaut.net/blog/2011/ring_introduction
IMO, whichever code generates your views should call the function, and use the result of the function to dictate how to render the view. Looked at from the Clojure perspective, Controllers could be seen as functions that are called by the router.
I have a fairly conventional Grails application. It's monolithic; although it's somewhat split into plugins along functionality lines, it is built into a single war for deployment. Due to company architectural constraints, I need to consider isolating the app's persistence into a web service (or series of web services). What's the best approach to dividing a Grails application into a persistence service and a presentation application?
Put your domain classes in a Grails plugin, and have two distinct Grails applications, one for your web front-end and one for your web service. Both access the database directly, but code for persistence is not duplicated.
Here is a blog post that have some more details on how to realize that.
I don't have an out-of-the-box solution for your problem, and I don't believe there is one. I'll just explain the solution I use and what I would consider in your case.
In my organisation, our approach is to separate our applications in a Grails back-end and a front-end in Flex. The reason is that we have many ready-to-use Flex components that would take too much time to re-implement using pure web technologies, but here's not my point.
Creating a REST back-end in Grails is quick, as views are scaffolded when appropriate, controllers are straightforward, and input validation is greatly simplified by Domain constraints.
The drawback of this split is that definition of domain objects have to be duplicated in the front-end. You might includes objects validation in the front-end or not, but if you omit them, it will have an influence on UI responsiveness (requests to the REST back-end in AJAX calls for real-time validation to get the errors). At the end, our application is quite cumbersome because modifying objects in the back-end implies modification in the front-end. Furthermore, we do validation in both the front-end AND the back-end, and this code is not shared, so it must stay in phase and maintained at two places.
Our applications are split in a way that's similar to two completely distinct Grails applications that would share no code. A solution that would work in your case but is not what you are looking for, for sure.
In your case, I see two viable solutions for the web front-end:
use the Groovy REST client library to fetch and send back your domain objects directly from your controller. If needed, pack them in command objects that reflect your domain objects, so that you can share validation code with the back-end.
create some kind of REST GORM that replaces Hibernate with queries to your REST web service. You could look at the GORM for Mongo Plugin as an example of how to create such a GORM replacement.
I like the last idea, it would be a useful public plug-in. It doesn't exist yet, unfortunetly.
I'm looking for an alternative to the awesome .NET (WCF) REST capabilities.
Why?
I have deep interest in open source technology, but when it comes to webservices I do not have any experience except with .NET webservices.
Besides, I'm currently using a lot of Java and Python, and I am moving away from the Microsoft technology stack.
Please suggest alternatives in any programming language, but explain why it's good or better for some reasons. (this reason may be be tightly related with the choice of language)
What do I want to know?
Ease of use
Installation
Configuration
Generation capabilities
IDE integration
Deployment
Learning curve
Pros and cons
etc.
Spring 3.0 REST:
Spring uses annotation based controllers, which can be used to bind a url to a method in the controller. Annotations are used to differentiate between GET methods and POST methods.
#RequestMapping(value="/hotels/{hotel}/bookings/{booking}",
method=RequestMethod.GET)
public String getBooking(#PathVariable("hotel") long hotelId,
#PathVariable("booking") long bookingId, Model model) {
Hotel hotel = hotelService.getHotel(hotelId);
Booking booking = hotel.getBooking(bookingId);
model.addAttribute("booking", booking);
return "booking";
}
Under the hood, the variable "hotel" in the URI string is converted to a long in the parameter list, as is booking. Spring REST can also marshal JSON objects into custom classes using this same technique. Note that this method is annotated as RequestMethod.GET, which means it's invoked for GET requests but not POST requests.
Spring 3.0 REST makes it easier to create RESTful Web services by eliminating the need to reinvent the wheel or marshal/unmarshal JSON text by hand from/to Java objects.
There is a demo here on the SpringSource Blog titled REST In Spring MVC. The learning curve is low, but getting the demo to work may take some time thanks to dependencies. Once you get setup and have a working demo, the hardest part should be over.
For IDE integration, check out Spring Roo. I've not used it, but I've heard it has some features that integrate with Eclipse IDE to make your life easier.
Restlets:
Restlets were designed solely for REST. As a result, the overhead is a lot lower than Spring 3.0. Restlets are better suited for cases where you don't have a GUI, and where you aren't concerned with MVC. Restlets can easily serve as both a server and a client. It also has an embedded server you can run, which eliminates the need for a container like Jetty or Tomcat.
I've had very little exposure to Python, but from what I've seen of Google App Engine's implementation of the webApp framework, the Router concept feels very similar. Those with a Python background may find the learning curve to be a lot lower:
#Override
public Restlet createInboundRoot() {
Router router = new Router(getContext());
getConnectorService().getClientProtocols().add(Protocol.FILE);
// Serve the files generated by the GWT compilation step.
Directory dir = new Directory(getContext(), LocalReference.createFileReference(new File("war/")));
router.attachDefault(dir);
router.attach("/contacts/123", ContactServerResource.class);
return router;
}
It uses GWT on the client-side; I prefer to take that part out as it reminds me too much of Java Swing. While some people may find that advantageous, my personal preference is to stick with the technologies that feel more like the Web.
Below is a simple example of a REST server using the standalone mode. The server runs on port 8182, and it listens for GET requests. It has a similar annotation-based model as the Spring REST framework, which also helps split up the different HTTP methods and point them at different methods in your classes. This is a very basic "Hello World" REST example:
public class FirstServerResource extends ServerResource {
public static void main(String[] args) throws Exception {
// Create the HTTP server and listen on port 8182
new Server(Protocol.HTTP, 8182, FirstServerResource.class).start();
}
#Get
public String toString() {
return "hello, world";
}
}
Check out the Restlet Web Site for more information and examples of the Restlets framework. Restlets has a slightly less learning curve than Spring because it's targeted to REST; as a result, it doesn't contain all of the extra functionality included with Spring that can sometimes make finding an answer to a problem difficult. Restlets are definitely the way to go if you're looking for something lightweight.
Both of these two frameworks will run in Tomcat, Jetty, as well as on Google App Engine.
If you are using Java and you are familiar with Spring, then you should certainly take a look at Spring MVC 3.x. This version moves away from the ugly XML configuration, and its syntax is very similar to JAX-RS's specs. That said, if you know Spring, then learning Spring MVC 3.0 is going to be minimal. However, if you are having trouble understanding with IoC pattern and what not, then it is going to be a long painful experience. :)
Keep in mind, Spring MVC 3.x is not pure REST, and it will never be in the future at all, based on the Spring MVC developers. Their take was there are already so many good REST implementations and there's no point of making Spring MVC 3.x totally RESTful.
Another option I will certainly recommend to you is Jersey. Jersey is pure REST, in another word, it is an implementation of JAX-RS. Jersey took me 30 minutes to learn. In my opinion, the annotations are so much more powerful and richer than Spring MVC 3.x. The annotations from Spring MVC 3.x seem pretty vanilla to me. Jersey will automatically generate the WADL for you, although it is pretty basic... but having one is better than not having one. You can certainly customize your WADL if you want. (By the way, WADL is REST's version of WSDL, if you don't know what that means). Jersey basically detects your package containing all the Resource classes and generates the WADL based on the configurations you have, pretty neat stuff. The last thing I want to point out is Jersey has a great test framework for you to easily test your Restful web service. In another word, their test framework allows your unit test to easily fire up Grizzly or in-memory server to test your web service. It is certainly one of the best I have ever use thus far. Here's a very easy tutorial for you get your feet wet: http://www.vogella.de/articles/REST/article.html . It is really THAT easy. :)
FYI, I have used both Spring MVC 3.x and Jersey.
ServiceStack is one of the more recent developments. I haven't done much with it yet, but it seems pretty sweet so far.
Ruby and Rails (Ruby on Rails) have great support for RESTful service. In fact Rails supports and encourages design and develop in RESTful manner.
Thanks to ruby's strong DSL feature, writing REST service is very straightforward and easy. Since you have python experience, learning ruby might be easy.
Refer to this guide to have an impression how rest urls (called routes in rails) are defined.
Other Ruby web frameworks such as Sinatra also do a good job on this.
BTW, the best things is that both ruby and rails are open source, and the ruby community is awesome and very active.
There's RESTSharp as a REST/HTTP client (open-source project) and OpenRasta
I welcome you to check out servicestack.net it is designed for simplicity and speed and introduces very low artificial concepts where it is able to maintain a very DRY and succinct API and automatically works out of the box without any configuration or code-gen.
It encourages best practices as it is modelled around Martin Fowlers Gateway and DTO pattern for developing remote services.
The equivalent code for the Spring.NET example above would be
Configuration (in AppHost)
Routes.Add<Booking>("/hotels/{HotelId}/bookings/{BookingId}");
C# Code
public class BookingService : RestServiceBase<Booking>
{
public IHotelService hotelService { get; set; } //auto-injected by IOC
public object OnGet(Booking request)
{
var hotel = hotelService.GetHotel(request.HotelId);
var booking = hotel.GetBooking(request.BookingId);
return booking;
}
}
A similar example to the booking service can be seen by the live Northwind Web Services demo.
That's all the configuration and code (exc DTO) you need to write for that service and it is automatically available via JSON, XML, JSV, CSV, SOAP 1.1/1.2 and HTML endpoints and formats automatically without any extra configuration required.
Checkout the Hello World example for more info on all the endpoints and formats provided as well as the auto generated /metadata and documentation pages.
There is an open source framework entirely developed for RESTful web services which is called Recess
It's not very old, but got good attention from the industry. Alcatel-Lucene already arranged a competition on TopCoder for developing some of their services using this framework.
Check out details at Recess web site