By backend I mean software systems that consume data, process files or communicate using machine interfaces (REST, SOAP, CORBA, etc...). No fancy web or UI testing is necessary. I have in mind Cucumber and Robotframework but I don't know how well suited they are in the task at hand.
There isn't an easy answer to this question.
Sounds like you got your domain right... because if you were trying to test UI/Web components acceptance testing frameworks make not be the right tool for the job.
You have a few options
SpecFlow
Cucumber
StoryTeller
FitNesse
mSpec
a few others.
I'm partial to StoryTeller & mSpec.. but each of these tools have their pros/cons.
Questions you should be asking yourself (and your team are)
Who is going to be writing/maintaining the tests?
Are self documenting acceptance tests provide value for your organization?
Which technology would integrate most easily with your current build process?
I have used Cucumber to test a batch application written in perl and plsql, an informatica transformation, and am currently using it to test a telephony ivr/queueing system. Ruby provided the gems I needed to drive the system and it was very easy for the testers to learn the language/syntax.
If it comes to Robot Framework I have an experience with bad support in Intellij for this. I'm using IntelliBot plugin. In many cases you will know your mistake like wrong syntax, cannot find keyword etc. late in test runtime.
Problems with finding imported libraries, no debug, no simple refactor like rename keyword across a project.
As part of a new job, I have to devise and implement a complete test strategy for the company's new product. So far, all I really know about it is that it is written in C++, uses an SQL database and has a web API which is used by a browser client written using GWT.
As far as I know, there isn't much of an existing strategy, except for using Python scripts to test the web API.
I need to develop and implement a suitable strategy for unit, system, regression and release testing, preferably a fully automated one.
I'm looking for good references for:
Devising the complete test strategy.
Testing the web API.
Testing the GWT based application.
Unit testing C++ code.
In addition, any suitable tools would be appreciated.
Testing Computer Software is a great soup-to-nuts book on the entire testing process. In addition to the items you mentioned, you'll need to think about other types of testing (performance, security, localization, stress testing, to name a few) and how to manage the test process; test plans, issue tracking, test data, test cases, in addition to the tools.
There's a lot there, and you can't do everything at once. I think a phased approach would be best, where you identify the gaps, weaknesses, and risks in the current process, prioritize them, then set up a high level plan to address them one by one.
Software QA Testing and Test Tool Resources is a good starting place for finding some tools to fit your process. StickyMinds is a nice web site dedicated to software testing, and the folks here at StackOverflow certainly know their stuff, so don't be afraid to ask.
Good luck :)
You can find a ton of excellent information on testing and developing a test strategy in general over on James Bach's blog. Specifically by searching through it for tips on testing strategies.
James is an excellent resource for information about how to do great software testing.
Best of luck.
There's a good conversation here on The Purpose of a Test Strategy.
As testing tools you could use Selenium for web testing and CppUnit for c++ unit testing.
I've been looking recently at Coldfusion for an upcoming job. My background is in ASP.net/MVC and JSP/Servelets.
From what I can tell, Coldfusion is mostly a presentation technology that interfaces with a business layer implemented in some other technology. For the trivial cases, it also looks like you can go straight from the markup to the database much like PHP.
I know this is probably a simplistic view of the product. So what more does it do and what is the business case for using Coldfusion over more heavily hyped web technologies like ASP.net/JSP?
You can definitely write your business layer in ColdFusion, and as you say you can extend that with easy hooks to java and .net objects.
The business case for ColdFusion is that it is a rapid application development platform - the speed that you as a developer can get things done is just insane. There is a lot of built-in functionality, from MS Exchange integration, charting, Excel generation, all the way through to a Hibernate ORM implementation (new in CF9).
There are a few popular, mature MVC frameworks (Model-Glue, Coldbox, Fusebox, onTap, etc) that you can work with, or you can run up your own framework using a pattern that suits your style.
What might be confusing you is that you can choose to write the presentation layer and business layer in ColdFusion tags, and that might be why you think it's not a powerful option for the business layer. CF tags wrap a lot of functionality in an easy to use syntax, but with CF9 you have the option to write ColdFusion Components (CFCs) completely with a script based syntax - that might help you distinguish between presentation (tags) and business logic (script).
The developer edition is free to try, so you really only are losing some time if you give it a go, and I highly recommend you check it out.
Riding on Antony's suggestions, he forgot to mention another MVC framework, ColdFusion on Wheels! We're rapidly approaching a 1.0 release by next month and have an active community developing a slew of plugins. With built a ORM that follows Rails' design, it's easy to pick up. Check it out and give us some feedback.
I m just starting using gwt and so far so good, however after reading some sample code I wonder is it necesary to have a high level of test coverage? (I can see that most code is declarative and then add some attributes I can see the sense in checking so me particular attributes are there but not all)
Also i would be interested to know anything about what are the gotchas in TDDing with GWT
I m using eclipse so also if you are really happy with some particualrs add ins for GWT I would be happy to hear about that
Thanks for the input
edit: maybe I m asking a very wide question, but even little pieces of information will help
I come from having nvelocity views with jquery/extJs/prototype/scriptaculous and this is a bit different
When designing GWT applications to be easily testable, it's best to move as much logic out of the view as possible. Use a design pattern which makes GUI testing easier such as Model-View-Presenter (MVP), which is used widely in building desktop applications (The C#/.NET folks have written a lot about this pattern.)
You can use GWTTestCases to test remote communication and code that ultimately executes raw JavaScript (most of the GWT core classes require this, especially widgets). However, these tests are slow to execute, so you should prefer designs which put all that logic in objects that can be tested in plain ol' JUnit TestCases.
For more information about writing GWT applications test-first, I've written an article for Better Software magazine, which is available as a PDF online at my blog.
I think the best reference at the moment would be this Testing Methodologies Using Google Web Toolkit
I think you asked a pretty broad question, which is part of the reason why you didn't get a reply for a while.
Compared to traditional AJAX web development, one could argue a GWT application requires less testing. Because the GWT team has worked so hard to make sure that its widgets work consistently across all web browsers, you don't have to worry about cross-browser compatibility nearly as much for your own application.
That frees you up to focus on your own application. Create a separate test case for each of your own custom widgets and test that they behave as you expect, and then write higher-level tests for each module. Take the extra step to make your tests fully automatable - that way every time you make a change or are about to release, it's easy to run all of your tests.
http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=DevGuideJUnitIntegration
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As a novice, I've spent time learning a smattering of C and a fair bit of PHP. I've looked at writing desktop applications for Windows, but there seems to be a fair barrier to entry due to complexity of APIs. Is it worth learning this, or will native applications become less common in the future?
The way I see it, the only desktop application I ever use is a web browser and a text editor as well as the obviously the OS itself. Everything I need is online now.
Is learning to write non-web applications a useful skill going forwards? If so, what should I learn?
I don't think it is ever a good idea to choose one side and stick with it religiously. I think a good engineer will expose themselves to as much as they can so he can make an informed decision about which is the best tool to complete a task.
In other words, don't choose a platform, OS, programming language, etc. and then ignore the others. It is best to be well-rounded in your skill set.
There will always be a market for native apps, although a lot of stuff is moving to the web and there's more scope than ever before for web based apps, native GUI applications are never going to go away entirely.
However, it's really, really hard to give you any really useful advice other than stick with what you like. If you use web stuff exclusively, it would be a bit foolish to go and become a windows GUI programmer :)
This may get modded down - but I'm going to say it anyway.
You can either program or you can't. About 18 months ago when I was looking for a new job, I was looking at the market and I was doing a lot of .NET but a few places wanted me to do JAVA.
I was doing Web Services, they wanted someone to do other stuff...At the end of the day it came down to this - if you know how to code you know how to code. If you're writing desktop apps right now and say in 6-8 months you want to move to some ASP.NET MVC, you'll be fine.
It may take you a bit of start-up time to learn the syntax and get a feel for some things - but in the end you'll be fine. I say this holds true for all the new languages...Skill is skill
Non-web applications will be very useful for the far future (as I see right now). We will not be able to do anything with the efficiency as a well written desktop application online using an interpreted scripting language that has to use a network protocol to communicate with the client.
However, if you are interested in networking, maybe you can try a little of both. Make an rss reader, a simple web browser, or an IRC client. Their all great projects.
You should learn whatever you want to learn. If you don't you'll probably find it harder going than you need to.
I personally started writing desktop applications for Windows, because I used it at the time. These days I do think that you're correct - you can produce a website / online-application without investing so much into the process.
But even writing a decent web application is going to be hard if you're new to programming. A standalone page is simple, but when you add databases, security, and administration into the mix then things can grow.
In my oppinion, a novice should conentrate on the basics and internals of the language of choice. Graphical or web interfaces should wait until you know what you're doing in the backend. I personally would suggest you start with console programs, but I guess that depends on the platform you're using. Maybe desktop interfaces are easier to start with on Windows.
The best practice (in my oppinion) is to write a solid backend with the functionality you want to provide and write it in a modular way, so you can later decide if you want to provide a desktop interface or a web interface (or both). The choice for the user interface shouldn't matter in the beginning.
Learning non-web applications will always be useful. There will always be applications that are not suited to be web apps. Even if everything moved to be a web application, the server side code and web browsers still need to be written.
At this point in time, if you're interested in the Windows platform then I would advise looking into C# and WPF. Those technologies are used in both native and web environments.
Web development is all well and good but the majority of systems even if they have a nice web front end still consist primarily below the web level, a bit like an iceberg.
End most web implementations are n-tier in design with the lower levels like data access and integration with peer servers ocurring in non web languages.
As I see it there seems to be one pervasive language that can touch all these levels and than is .Net Framework. Notice I make no specification about c#, vb etc. I consider that to be a matter of taste. However I can't remember seeing an n-tier banking website using php to do the data layer. Nor an online ordering website that would use ruby to talk to its jd edwards server.
This is where the heavyweight languages still pervade and if thats where you want to work then learning the .Net framework in whatever language variant you choose is the way to go.
Master one discipline then move to the next one.
I am also at the very infancy of learning business application development. The very step I took was to study database. Majority of the applications in the real world is data-centric. It is good to start with desktop application. Do some drag-and-drop then study the code behind. I am doing the same thing with ASP.NET. I have downloaded tons of starter kits. It all depends on your learning style. For me, I can learn more easily by "learn-by-doing" than by digesting chunk after chunk of set theories. That is why cookbook and headfirst books perfectly work for me.
I believe that the future development model for "Web" applications will more akin to the current model of desktop application development. By which I mean that tomorrow's Web apps won't be HTML/AJAX efforts that are difficult and expensive to maintain, debug and test, they'll instead be developed with compiled languages that target a platform that's already available in the browser. Flash, Silverlight, and (to a lesser degree, it appears) Chrome are the current paragons of this idea.
So maybe it's not such a waste of time to learn those "complex" APIs. My group builds WPF applications and I personally don't find those to be any more complex than the the current crop of HTML/AJAX projects.
From your background in languages, I noticed you only mention PHP and C. Neither language is strictly speaking an object-oriented/OO language. You really should learn a traditional OO language like Java or C#, as the majority of jobs are looking for those skills. BTW, read Yegge's advice on what languages a professional developer should learn, and think for yourself about what you should do.
Assuming that you're interested in enterprise application development, I would have to say that that field is transitioning from traditional web development (present stuff from a database on a web page) to rich internet applications (still present data from a database, but the front end begins to approximate a desktop application). Building a rich internet application will require concepts that desktop UI developers have known for a long time. Therefore, I don't think you have to chose between web development and desktop development.
I agree, you should learn what you want to. Once you have an understanding of Web, then learn some desktop programming to broaden your horizons a bit. You'll never know when you'll need it.
But, also, if you're looking at learning windows desktop development, then you should definitely look at C# and/or VB.NET. The .NET Framework is by far the easiest way to develop desktop app for Windows; much easy than C++ from what I understand (I actually didn't spend much time on C++ myself).
#Rich Bradshaw,
I think you can get answer on your question by looking at any job seeking site.
what should I learn?
Whatever you like and can bring you enough money.
Thats a very good question.
I know nowadays that most app development that im aware of is web apps.
But with languages such as flex , i wouldnt be suprised if the desktop apps came back again.
To be well versed you should do both. Skills in one area may or may not translate into the other very well. The lack of state for example trips up lots of desktop developers when they start building web apps. Of course, your experience may vary
A professional .NET programmer should handle both webform and winform.
Even you start from webform, but finally, you will have chance on touch winform.
Just like a topic "VB vs C#", you will not see a .net expert talk about that, because finally, you should know both of them.
There will be cases where things beyond the web can be used:
Scripting languages/console application - build scripts come to mind here for an example but also writing batch or command files to do simple tasks like handle deployment or to do some other simple task that is likely better done from within a black box rather than manually doing something over and over again.
Windows services(WCF) - These are also possibly useful for monitoring things and sending off those, "Server is down!" messages for someone to go and find out what went wrong.
There is also something to be said for middleware and back-end development where one would write web services or handle querying a database or inserting data into a DB that may not be the same of front-end web UI work, just to give a couple of other examples of software development work out there aside from the embedded systems and mobile stuff that is also non-web and non-desktop development in a sense.