test driven development, literally
Hi, I'd like to know if are there anyone whose dev team is using testcomplete during development? for example write test to reproduce error or write test how application should behave when working ...
Forum Discussion
Hi Mika,
I think that answers to your questions depend on the project.
In a nutshell: it is my opinion that TestComplete is a tool for functional regression testing, but not something that is worth to be used during active development. Unit testing tools seem to be more suitable for this.
From my experience, I can recollect, probably, only one project where classic test-driven development could be applied. That project was for the mature product with strict, well defined and well documented requirements as for UI and UX behavior. New UI design or UI changes were thoroughly planned initially as well as business flow and nobody was allowed to make changes after that without going through the serious change procedure.
In a 'modern agile' development, when everything change without prior notification, too many efforts will be spend on tests support.
Another point: TestComplete has its own project structure and tests are created using scripting language. This means that developers will have to deal with and support two separate and quite different development environments.
One more point: I had a project once when developers were asked to help with creation of tests. It was an interesting experience for me, because (to my opinion) developers wrote the code that is usual and fine for the application code (and unit tests), but not always fine for functional tests. For example, it was quite usual to see the code like
if (user.exists) then {...}
This is usually fine for the application, but for the functional test quite often 'else' part is required as well to signal that for some reason the user was not found.
Also, it is expected from developers to create a well designed and structured code. While this is also applicable to the functional test code, it is a usual situation when the functional tests *must* be executed within a tight time frame and if test code problems exist (including those caused by design/functionality change) these problems *must* be corrected before the end of the test run. In the situation like this, test code simplicity is often more vital. This means that developers will be forced to maintain 'good and clean' code for the application and switch to somewhat different coding approach and style for tests.
If your tested application is created using .Net, you may consider TestLeft (https://smartbear.com/product/testleft/overview/) that is based on the same technology as TestComplete/TestExecute but is more developer-oriented.
I'm with AlexKaras... while there is some part of TestComplete that can help with TDD, I think what you're suggesting might be a bit beyond... definitely look into TestLeft.
As it is, though, you can play the TDD role in an Agile/Scrum/KanBan environment. As you're developing new features of the application under test, you can start building out your regression automation. Having a good framework for doing so will help with that, of course. But you can start writing classes, building out functional routines, etc., based upon the assumptions from the specifications and requirements. That way, when the feature is delivered, you can start plugging it in.... and, if the feature doesn't match what the requirements communicated SAY it should, you can go back to the dev team and say, "Hey... this isn't meeting the documented requirements." Not exactly TDD, but it IS a QA role that automation can fill.
If you do end up using TC tests for developers just to run, then consider giving them TestExecute. They're not going to analyze the test results, they just need to know if it passes/fails.
Well... My initial reply was with assumption that developers will create tests during development and execute them then.
But if the idea is to provide them with already existing tests that developers will just trigger and check their results, this may be a good idea. With the only note that either tests must be extra stable and reliable so that they do not fail because of low performance of the tested application or other false negatives, or, alternatively, someone from test team must provide assistance with test logs analysis to separate false negatives from real failures. And this assistance must not be considered as something that can be done while coffee machine is making another cup of coffee. Usually, such logs analysis is a serious task that requires a reasonable amount of efforts.
Hi,
Thanks for Your replies!
I (of cource) forgot to tell about our product.
It a legacy application, part of code base has been written in Turbo Pascal 3.0 , but of course updated. So currently working with Delphi 2007, migrating to D10.1 New functionality is added weekly, sometimes daily.
We do add units tests, but when some part of program is huge case statament, with strictly coupled code, unit testing can be hard. We are working to improving unit test coverage, but it's a long way...
But I'll thing these points and we will make some kind of movement.
thanks again!
