G'day guys,
I've started a new role at a company and am working on a rails application that's used internally for particular management applications. At any rate, there are no unit tests associated with this system, and as I am building the system out I've realised there is a serious need to build unit tests so that I can have regression testing as I continue to add to this codebase.
It's a rails 1.2.7 app that I cannot migrate for reasons of compatibility, but I will be beginning to port components over it to 3.0 in the background.
There is currently only the built in tests that rails makes, and I would love some insights into how to get started with building small tests into the system and particularly at what aspects would be good to start?
This system builds a lot of individual config files, so I'm assuming a lot of the test generation would begin with testing those config files for individual aspects/elements and going from there.
I've had a look at cucumber and rspec, but just wanted to find something straightforward and easy to use that I could slowly build upon within the current system and build up a testing base over time.
Any insights, links or others would be really really appreciated.
Cheers!
A lot has changed since Rails 1.2.7, definitely one of the first things would be to right unit tests, but instead of going an all out unit test attack.. Attack the problem component,
Write tests
Upgrade the component
Run Tests ( mostly they'll fail / possibilities of errors )
Make them pass
Refactor ( May be the new features at your disposal )
I usually do the above steps with writing the integration tests, and functional tests and unit tests for the components in the integration tests.
All the best, this ain't going to be a simple task :).
Related
I'm trying to use SpecFlow for a .net project. I'm new to SpecFlow. The Development team are using NUnit, so it would seem that SpecFlow would be a good option in conjunction with Cucumber. However, the Development team have come back say that SpecFlow cannot be used saying they do not have an API/Service that is available to use at the level required. Currently all of their automated tests are through the UI using Test Complete, I am keen to move to API level testing.
Can anyone explain to me why SpecFlow cannot be used, I'm sorry it's a newbie question but no one can answer it, I've asked everyone I can think of, surely the first steps would be to see if we can use SpecFlow with NUnit but perhaps not.
Can anyone give me a guide on my next steps, how can I be sure this isn't an option without righting it off without concern that it's just being blocked?
Thank you
SpecFlow has a unit test generator that generates unit test code for a variety of unit test frameworks. SpecFlow generates NUnit tests in its default configuration. The getting started page on specflow.org explains a quick way to get up and running with SpecFlow and NUnit, http://www.specflow.org/getting-started/.
If the UI is HTTP based, SpecFlow can be used with WebDriver or another browser automation framework to test the UI. This blog post provides an overview of how to get started with SpecFlow, NUnit and WebDriver, http://blogs.lessthandot.com/index.php/enterprisedev/application-lifecycle-management/using-specflow-to/
I am unclear on the API you want to test. If you could provide more information on the specific API and UI you are trying to test, I could possibly provide some code examples or references for you.
Is the API exposed through HTTP?
Is the UI a web, mobile, or desktop
application?
Have you tried to use SpecFlow at all?
SpecFlow doesn't run tests. It simply maps readable language to tests. If their test can be written as a nunit test, then SpecFlow is available to you to use. With no change, here is how it would look.
Scenario: Running 'testname'
Then I execute the test 'TestName'
You would map that to
[Then(#"I execute the test '(.*)'")]
public void ExecuteSpecificTest(string testname)
{
// Using reflection, execute the method listed
}
Obviously you would want to do better than that. You want a given, when, then so you clearly show the setup, action, and then compare expected verses actual result but it isn't necessary. Best practices however is another discussion.
To sum it up, code is code and SpecFlow simply maps to code. You can use WatiN, WebDriver, or anything else to hook into the UI or an API. SpecFlow doesn't care. It simple executes the methods without knowing what's inside.
I've got an Erlang project comprising a bunch of different applications. I'm using Common Test to do some of the testing.
apps/foo/suites/foo_SUITE.erl
apps/bar/suites/bar_SUITE.erl
I'm starting to see duplication of utility code in those suites.
Where should I put my utility code so that it can be shared between the two suites?
I've considered adding another application:
apps/test_stuff
...but I can't make the CT suites depend on this without making the application under test depend on this (or can I?). I don't want to do that, because test_stuff is only needed when testing.
I have a similar problem with my eunit tests, both between applications (apps/foo/test vs. apps/bar/test), and where I'm using similar functionality between the eunit and CT tests in the same application (apps/bar/suites vs apps/bar/test). Can I use the same solution for this case as well? Or do I need to ask another question about that?
Do you think ct:require/1,2 could help you so that foo and bar SUITE would require test_stuff before it gets executed? For more information http://www.erlang.org/doc/man/ct.html#require-1
It depends on how you are packaging your final releases. For example, I use rebar for relase management. I have Cowboy fetched along with other dependencies for testing purposes, but in my reltool.config, I omit it, so it doesn't get packaged with the final product. I use rebar to run Common Test, and it's able to add Cowboy to the path without having it bundled as a lib with everything else or added as a dependency to the app I'm testing.
However, if you have another process which infers your release configuration from your dependencies, you'll have to find a way to exclude your test code when you generate a release.
I would like to perform the following iPad/iPhone testing scenario automatically:
Tap Edit box A
Type text "abcd"
Verify button B is high-lightened
I understand UIAutomation 4.0 allow you to write a simple JavaScript to perform the above steps. However, UIAutomation does not have test infrastructure ready. For example it lacks testing macros to show if any tests failed and does not have a clear way to run setup and shutdown for each test cases.
That is why I look back to XCode unit testing. Logic tests won't work for me. How about Application tests?
Basically, I am looking for something that can do GUI testing and at the same time has test infrastructure. It is even better if it can be integrated to continuous build environment.
Check out Zucchini. It's just come out and I saw a demo at a recent YOW! conference. It's basically a BDD testing framework that uses coffeescript for scripting and runs against an actual device. It's also fully runnable from CI servers which makes it perfect for agile teams.
I haven't run it myself yet, but it seems to exactly what I'm looking for and No I don't work for PlayUp :-)
I am working on a Django project. And our team follows agile practices(TDD,very short launch times etc..)
When it comes to deployment stage of a feature, we follow manual procedures to get the code deployed on to our production machine. Manual procedures in the sense, run the test cases (of the entire project) manually and run the syncdb (or any latest db changes) manually and other stuff.
This manual stuff is taking about 1/2 hour per day,everyday. So I wanted to automate this. So is there any automatic deployement system or something that takes the commands I give and do what I want or it should be done only MANUALLY?? (using a simple shell file which has got all my commands. In which case, I need to learn shell programming a bit because I don't want to update my latest code in my production machine if any test case fails. So such a sort of conditions exist for deploying, which may involve a bit of shell programming. I guess!)
I just started researching this myself and it looks like the Python-equivalent of Capistrano is Fabric, although maybe not as mature. There seem to be a growing number of people wanting to switch over simply because Capistrano is too ruby/rails centric, although I haven't seen anyone complain about Capistrano being incapable or lacking. YMMV. More info here and here.
EDIT: Looks like Fabric is undergoing a lot of changes. They're moving their homepage to http://docs.fabfile.org/
So in Agile terms, you've identified duplication in your deployment process, now you're looking for ways to refactor it. ;-)
In the Ruby/Rails world, you'd turn first to Capistrano or Vlad The Deployer, and in the Python/Django world you'd turn to the equivalent, except AFAIK there isn't one.
It seems from this post that Capistrano has been used successfully to handle Django deployment, so that's an option worth exploring.
Beyond that, why would you need shell programming? You have a super-powerful scripting language in Python - why not automate your manual process in that?
How does one setup DUnit Testing in a Midas/DataSnap project in Delphi 2006
Edit
How does one set up a Dunit Test into a TRemoteDataModule
The project wizard in Delphi 2006 does not work with TRemoteDataModule
The question doesn't entirely make sense. Unit tests are performed in a separate project, not within your DataSnap server. Generally, tests which connect to a database are integration tests rather than unit tests. What is it, exactly that you want to test? If it's utility methods within, say, a TRemoteDataModule, you should extract those out into a separate class as class methods, and test them there. You should not have to instantiate an application server to perform unit tests.
Sorry for the terse answer above, the iPad posts whenever I hit return while editing a post.
dUnit is designed to perform unit testing, and what you are trying to do is NOT unit testing.
A test is not a unit test if:
It talks to the database
It communicates across the network
It touches the file system
It can't run at the same time as any of your other unit tests
You have to do special things to your environment (such as editing config files) to run it.
It can't run in isolation
If you follow the SOLID principles (especially the single responsibility principle), using dUnit to test your class (without testing the Midas/DataSnap related logic) should be reasonably simple. And really, you shouldn't need to test the Midas/DataSnap logic.
But there are ways to perform integration and behavioural tests on Delphi applications.
Personally, I wouldn't use TestComplete because it doesn't integrate well with any sort of CI server and the tests are stored in a proprietary binary format (which makes merging differences or maintaining changes in any source control system problematic).
You could try dSpec, but I'm not sure Jody Dawkins is maintaining it any more.
I have used the AutoIt BASIC scripting language directly on some projects, and also used its .NET assembly to drive a Delphi application using NUnit and C# on another. While not perfect, the NUnit / C# solution was more elegant than anything I'd seen for performing functional / behavioural testing Delphi applications. It did take some effort to get it setup though.