Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have code completed a project almost 50%, but haven't written any test code. I want to write rspec, capybara tests. Now this is reverse of what actually is done in testing. What should be my strategy here from where should I start (from model, controller, feature) and what should be my approach. Also are there any tutorials for this
Usually it's better to start from feature tests. They are easier to write and they provide most of coverage because cover a lot of functionality at once.
Also you will need not so many feature tests comparing to unit tests, for example. Because they are on top of the Testing Pyramid
When you will achieve decent coverage you can start throwing in unit test and refactor your codebase. Having feature tests you can eliminate the fear of refactoring. As soon as you haven't write test before the code your methods would be probably hard to test without additional refactoring.
That's is an additional advantage of having feature tests before unit tests.
You can find bunch of articles describing how do people usually test their projects.
As an example here is an article from Thoughtbot https://robots.thoughtbot.com/how-we-test-rails-applications
I would also recommend the Working Effectively with Legacy Code book.
It describes how to start covering projects with tests and then refactor the parts.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I joined a startup where my boss, so called Technology Head with 3 years experience has written the code and the website is running, She doesnt know testing and things are breaking apart now.
I have been Following TDD in my life, now I dont know how to test the RAILS APPLICATION where 50k LOC has already been written, waste code has piled up and there is no proper flow of the code at all.
How can I unit test the existing modules?
How can I refactor the maximum code with Test After Development approach for the existing code?
I am going bonkers with the existing code.
Cant make it again, not sufficient freedom to make it again.
Thanks in advcance
You could write a book on this subject (in fact I belive Mike Gunderloy did - Rails Rescue Handbook - though I can't seem to find a place to get it online now).
The short story is:
Unfortunately, it doesn't make business sense to retrospectively write tests for everything in the existing code base if it's basically working, so don't do that.
Start always writing tests for new features, and insisting others do too.
Whenever something in the existing codebase breaks, be sure to write a regression test.
When you make significant changes in the existing codebase, if it makes sense, add tests at the same time. Don't bother adding tests for small changes that can be easily manually verified; it likely isn't worth the time.
You probably already knew all that though. Good luck!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I really like the idea of TDD and BDD testing with rspec and cucumber, however I'm not entirely sure when to start those things with a new app. I don't want to start too early because it seems like not that great of an idea, but at the same time I don't want to expand the app too much before I start testing.
So my question is - when to start writing tests?
I'm planning on making a simple app with Rails and would want to use all the best practices I've learned about.
Contrary to what you said about "starting too early" some development strategies (ie Test Driven Development), one of the first things you do is write tests, the tests will obviously fail, and then you write the code that makes the tests pass. This way you can clearly define what you want your app to do (and not do). Some studies have found this approach to be highly productive.
#JTG is right, with the caveat that if you don't know understand what you're going to develop, which happens early on for many, you may need to develop without tests at first. This helps programmers early on to learn about their environment and what's involved in the build process.
If you do not write tests before you develop, you can go back and write those tests, alter the code so the tests fail, then change it to make them pass. This is not the best way to move forward once you know what you're doing, but can be an acceptable workaround in the meantime.
Well, provided answers are great, but if you say that you like the idea of TDD it means you like writing tests first(and some other TDD ideas).. That is why I am a little confused about your question (sorry if I misunderstood you). Anyway here is what I think about it: Don't be afraid of writing tests at the very beginning. According to TDD you write test just for you next development step. So at start it is very likely that your tests are simple. One for example may just expect an action to return successful response. Then you make it pass implementing controller and the action, and so on.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I went to one company. It's some big international product on Ruby (as they say).
So first day I came there - I look at their code - and it has long methods (pagedown each, many nested if's, inline calls to external libraries - nightmare), and almost no tests.
They say company is on the market for a year or so, it has 20 programmers that all work on same product, but all I see for now is that part of them finds bugs, and other part randomly fixes those bugs (which they make themselves because they treat tests as something they don't have time to do).
Has anyone worked with such products?
I know how bad a program without tests and refactoring can get. But they ask me to learn the product better before making a decision. Am I not getting something?
There are a lot of excuses. None of them are valid. The problem also is that it is a slippery scale. Once you stop writing tests, or did not start writing tests, it is a hellish task to start adding tests to old code. Tests are documentation, and a lot of documentation is missing without tests. So you will not know why specific parts of code are there, or why they are (at first sight) that bad. Sometimes there is a good reason.
Tell your boss that a good way to learn the product is to write tests. Start with cucumber, because that way you do not need to know the insides of the application. Check your test coverage (e.g. with simple_cov). That gives nice measurable feedback (progress). Then focus on model tests.
Be the change. Educate. If that is not possible, draw your conclusions :)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
My Proj Manager asked me to write a BDD.
What should a BDD written for ?
Should we write a BDD for each Story or for each epic ?
Normally (there are, as always, exceptions), you start by writing your user stories in a format that BDD tools can read (a format similar to the Gherkin language). The user stories can then be implemented and executed by the tools as tests.
A programming language neutral intro to BDD can be found at Wikipedia.
BDD is Behavior Driven Development. As a result, you have a specification that can be executed via some testing framework, thus ensuring requirement completion. Each User Story usually has several scenarios. Here is an example from our project:
Given Bug (Task, User Story, Feature) view
When I expand 'Actions' menu
Then I see 'Attach to Request' link above the 'Move and Copy' action
When I click 'Attach to Request' link
then I see requests lookup
[image of the lookup]
It is better to create scenarios that can be automated. It is challenging, but doable. Here is the more complete example of BDD scenarios:
http://www.targetprocess.com/blog/2009/10/bdd-and-user-story-specification-examples.html
Even with simple Given -> When -> Then format you have a good structure for your user stories, so it is worth to use this format without automation. Still automation is a huge benefit that BDD provides.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
This app had virtually no tests in place when we came to it and now there are cucumber tests covering the most essential parts. We are not sure if the app is working correctly and have had many disasters happen over the course of development, most of them caused by bugs that were never discovered. The code is quite ugly in places with models generating HTML and PHP-itis in the views. There are many extraneous models and controllers that could be greatly simplified or eliminated. My question is, when is it better to simply refactor code without testing previous functionality? Due to deadline constraints, it's very hard to justify spending time on covering all the existing code with tests when we know it's bad and could be easily eliminated.
I'm gonna guess this is a client project. My approach would be to write Cucumber tests to cover the behavior of the project only, and then write RSpec implementation tests that cover the new code you'll be writing.
Get the client to sign off on the behavior tests, this way, when you start changing the implementation, you can be sure you haven't drastically modified the behavior of the app. Then, write the tests for the code you wish you had, and refactor until the tests are all green.