Testing is good
I have created too many web applications and witness many forms of testing methodologies that was designed and created for making the developers and QA life much easier in creating quality web applications with an agile software development life-cycle. As the technology growth over the years still it was not an easy task to create such testing environments and especially when it comes to the actual web UI testing.
In general we can split the web application development to two major sections. The first is the logic layer and the second is the actual UI component and the view layer.
Well, for most programmers the logic layer is the much straightforward section and relatively to the UI layer had better understanding and more accurate solutions.
In the latest client era where the client machines got stronger and the JavaScript frameworks became the main environment for the web application development, the test frameworks also got to get a boost. Most of those testing solution are about testing the JavaScript code, here are some of the players: Jasmine , Chai, Mocha and QUnit. And on top of that you can use Karma solution that will give you to run your fine tests on the real environment.
Don't get me wrong but recently I participated in a few conferences and met developers from different environments and still didn't get the chance to meet a development group that really tests their products as part of their development life-cycle. There's another parallel world where I get to see more Crowd Testing and Manual Testing and it speaks for itself.
In the web UI testing section still the big player and sometimes behind the senses actor is Selenium. You can record and replay your web application and get to really test your web components. If you want to automate your application and test its UI components this tool is your saver.
Don't get me wrong but recently I participated in a few conferences and met developers from different environments and still didn't get the chance to meet a development group that really tests their products as part of their development life-cycle. There's another parallel world where I get to see more Crowd Testing and Manual Testing and it speaks for itself.
In the web UI testing section still the big player and sometimes behind the senses actor is Selenium. You can record and replay your web application and get to really test your web components. If you want to automate your application and test its UI components this tool is your saver.
Agile Software Development
Everybody is talking about agile and it's the best news that we could get for the software development. Although I can still see developers creating features that the user will never get to use because they think it's cool, still the development life-cycle become to be much faster and more focused.
Can we say the same for the testing section?
It really depends what we are testing and what are the testing tools, but in the web UI testing section it's far from being agile. The thing is that tools like Selenium are working on the web application's output (DOM) and this is the biggest obstacle on the way to find a good solution for the web UI testing. The real web developer source project is about the JavaScript application's code that renders the application's output (DOM), thus testing the output doesn't really help in the daily agile development life-cycle.
Working with such development life-cycle is going back in time. Think of a situation where the developer creates a piece of code that renders a UI view and then the QA guy is creating his tests for the same view. Only when the QA person has finished his test cycle, only then the developer gets to see his report and that's my friends it's too late since our developer has changed the view already.
It really depends what we are testing and what are the testing tools, but in the web UI testing section it's far from being agile. The thing is that tools like Selenium are working on the web application's output (DOM) and this is the biggest obstacle on the way to find a good solution for the web UI testing. The real web developer source project is about the JavaScript application's code that renders the application's output (DOM), thus testing the output doesn't really help in the daily agile development life-cycle.
Working with such development life-cycle is going back in time. Think of a situation where the developer creates a piece of code that renders a UI view and then the QA guy is creating his tests for the same view. Only when the QA person has finished his test cycle, only then the developer gets to see his report and that's my friends it's too late since our developer has changed the view already.
Just imagine the amount of the QA's reopened and new issues.
Semi-Agile
It looks like we get to have an agile development life-cycle with web UI testing excluded. It's not that bad, it just mean that we could do a better job and maybe think of a solution to get a faster development and better quality for our applications.
As a developer I need to code tests, hell yeah!
Correct me if I'm wrong but I have not met many web tier developers with the urge of testing their code and if they do, it will be partly done. The developers tend to count on the QA guy when it comes to testing the web applications. In the below section I'm trying to bring new methodology where the developers will be responsible for their actions.
CAT, the new methodology behind the solution
My starting point was the daily pain of creating (Mobile) web applications and spending a lot of good time on the existing development life-cycle. It lead me to get out of the daily box and I came up with an idea that might put some light on the web UI testing section.
I tested my solution on many different environments and target devices. For example, here you can see JQM's kitchen-sink application tested with CAT. You can see the live demo in here.
The first thing I thought about was, the responsibility of the developer to bring the quality before it gets to the QA. This is the key point for getting a better and faster development life-cycle.
From that point I thought about how can I achieve that and with smooth integration for each part of the development persona. It means that the developer will have an easy way of implementing his tests side by side with his application's code project, support for the test environment with the existing application's CI and no changes on the production build process.
The first thing I thought about was, the responsibility of the developer to bring the quality before it gets to the QA. This is the key point for getting a better and faster development life-cycle.
From that point I thought about how can I achieve that and with smooth integration for each part of the development persona. It means that the developer will have an easy way of implementing his tests side by side with his application's code project, support for the test environment with the existing application's CI and no changes on the production build process.
The idea is pretty much simple, it's all about using annotations within comments. In those annotations the developer will describe any additional functionality that will be part f his test code it can be an additional JavaScript code, an assertion or part of a big test case. In that way any changes to the code can be immediately verified and tested.
Those annotations are in hibernate state and the test code does not exists since the annotations are in comments. The master branch will remain the same with the additional comments and with no additional code. On production the comments will be removed completely since the minification process is involved.
Only when the developer initiates or as part of the CI, CAT will be running over the application and a new test deployment will be created, including the application code and the actual generated test code.
The test deployment can then be deployed on the server. CAT runner can then be executed and run the application on any pre-configured browsers and/or devices. The magic is that CAT call the tests within the application itself. It means that running the test deployment executes the application's tests within the application's natural runnable environment on its natural flow and on specific scenarios.
CAT is an NPM open source solution, all you have to do is run:
Additional information is available at our site. Any comments or thought are most than welcome.
Those annotations are in hibernate state and the test code does not exists since the annotations are in comments. The master branch will remain the same with the additional comments and with no additional code. On production the comments will be removed completely since the minification process is involved.
Only when the developer initiates or as part of the CI, CAT will be running over the application and a new test deployment will be created, including the application code and the actual generated test code.
The test deployment can then be deployed on the server. CAT runner can then be executed and run the application on any pre-configured browsers and/or devices. The magic is that CAT call the tests within the application itself. It means that running the test deployment executes the application's tests within the application's natural runnable environment on its natural flow and on specific scenarios.
CAT is an NPM open source solution, all you have to do is run:
npm -g install catjsAdditional information is available at our site. Any comments or thought are most than welcome.
