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 6 years ago.
Improve this question
I am looking to run Nunit test but I do not want the tests to be data dependent.
For eg: If I am running my unit test on testing server referring to testing database and if some user changes database values;
it should not have an impact on my testing scenarios.
However I want my testing scenarios to refer to oracle Stored procedures.
Thanks....any help would be highly appreciated.
Also I am open to the idea of any other tool which has the ability to achieve this.
If you are really hitting the database this not a unit test but integration test.
Basically you have two options which one with it's pros and cons:
Keep with the idea of integration tests but ensure somehow that the data you are using is as you expected. This can be achieved using stored procedure in your testing database that recreate your data while calling it, you can call this procedure in your tests initialization and then do all of your testing. The main disadvantage here is that the test will take more time than unit test and will cost more resources.
The main advantage is that you can be sure you're code integrates well with your database.
Choosing to use a real unit tests, in this option you will not going to use the database at all but instead create in-memory objects that represents the data from your database.
Because you will create this objects in the arrange part of your unit test you can know extacly what data they are holding.
The main disadvantage here is that you can't be sure you're code integrates well with your database.
The main advantage is that the test will take less time than integeration test and will cost less resources, moreover your test can be run even if your testing database is down.
If you want you can actually choose to use both options, this is useful because each test is testing your code from a different perspective.
More about unit tests vs integeration tests can be found here.
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
What is the basic difference between, a test automation framework and a testing tool?
For example nunit is a test automation framework, but on the other hand Resharper is a testing tool. Both are used for testing the C# code.
What is the difference between them?
I mean why is one called a test framework and the other a testing tool?
The testing framework is used to describe your tests. E.g. NUnit or XUnit are used to write unit tests.
The testing tool is a tool that executes tests. Resharper for example will not just execute your tests and show you how many succeed, but can also measure the execution time of each test, analyze them and measure the code coverage.
In short:
testing framework: describes any kind of tests
testing tool: works with this tests (e.g. analyses or executes them)
In the extremely general sense, frameworks, runners, report writers, etc. are all tools. In common use, "tools" means an executable that does something with your tests or test results. The most common tool is a test runner. Other tools measure performance or coverage, produce reports, etc.
Since you mention NUnit, it consists of a number of different tools together with a test framework. The NUnit framework is packaged as and often called just plain "NUnit."
The NUnit team produces several different runners, including the console runner and two VS adapters. A GUI is being developed separately (by me). Other runners you can use with NUnit include Resharper, TD.Net and NCrunch.
Testing framework
repeat steps for check given input and output of given aspects(functionality or quality) in all live of project.
steps - one part of test that is execute something or tests aspect.
Testing tool
Checks quality of aspects(code, structure, standards) in given situation.
Summary
Tools are more technical stuff like, voltometer - you check actual state of stuff.
Framework is like creating environment to execute action (like possibility to press button).
Testing framework: Is a framework which is used to write test cases as per expectation like Xunit, Jasmine
Tool: is a tool which uses test cases written using testing frameworks and gives analytics of test like how may are pass or fail so, tools are like resharper, vs testing tools are popular
Hope it make sense.
happytesting
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 6 years ago.
Improve this question
I have a test suite which works against a dedicated copy of the real database. The application creates a complex object by filling it from the database and it would be a lot of work do create one "manually" or mocking one to bring it to a valid state. So I ran a database query from the tests in order to have a valid object (not to verify that I integrate with the database correctly). It was working blazing fast. Especially after the first call MSSQL was caching it and the query ran in less than 1 ms.
Are there any arguments why I should avoid doing this? If it's because speed when the database is on the same network it's working fast? It seems that most literature out there wouldn't recommend doing this - but why?
EDIT - To answer my own question: "unit tests" means that each test is autonomous, if you touch the database one test could modify it and affect another test. Even though transactions can solve it, it's still not quite in the "spirit" of "unit tests" and make them a bit cumbersome. So this should be avoided but not under all circumstances, if I have no choice I'll access the database in transaction which will make sure it won't affect other tests.
This seems to be a principle some people follow - that you should never hit the database - but my experience is that sometimes, trying too hard to avoid the database creates these giant tests, over-use of mocks, or a strange and brittle data access interface. Search about for test-induced design damage for more on this idea.
For my part, I'm happy to access a database as part of tests. You can often do write tests if you can wrap the whole test in a transaction, too.
We split up our tests in unit tests and integration tests/dlls. The unit tests cannot go to the db, the integration tests can.
Keep in mind that having a lot of integration tests can seriously slow your build. I can run all my unit tests in minutes while running the integration tests take over an hour.
You have to define for yourself WHAT you want to test? Do you want a test that simply checks if your API does what it should? Then you can mock even that single database-entity from your tests and test if your code goes right. Need an integration-test including database-traffic, network, ... ? Test your real-world scenarios including the code that is neccessary to get and manage your entities. So it depends on what you want to test and what you expect from those tests.
Considering the DB-performance should play no effect on this decission as you cannot relate on any DB-specific optimization in your tests. What happens when you decide to change the DBMS to something without this kind of optimization? Than your tests will fail which is doubtfully what you want. Performance should never affect what to test, however it might play a rule on how to do so.
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 2 years ago.
Improve this question
I am working for a consulting company that develops a lot of Add-Ons for SAP Business One using .NET. I want to introduce TDD (or at least some good unit testing practices) to the company to increase code quality. Here's the problem.
SAP provides a COM object (called Company) that lets you interact with the data in SAP. Company is an interface, so it can be mocked, but the amount of Mocking that would have to be done to get a single test to run is huge! I've tried it out with a few tests, and although they work, I really had to have a good understanding of the internals of the unit that I was testing, in order to create tests that passed. I feel that this very much defeats the purpose of the unit tests (I'm testing the internals as opposed to the interface).
Currently, through the use of dependency injection, I've created a Mock Company object that returns some Mock Documents that will sometimes return Mock values based on different circumstances, just to get the tests to run. Is there a better way? Has anyone been able to effectively unit test code that heavily depends on some external library? Especially when the results of the tests should be some change to that mocked object? (Say, when the add-on runs, the Mock Company object's SaveDocument function should be called with this Mock document).
I know this may be a strange question, but the fact of the matter is that in order to get these unit tests to run well, I feel like the only option to me is to create a really...reaally large mock that handles multiple Mock Documents, knows when to give the documents at the right time, and a lot of other things. It'd be essentially mocking out all of SAP. I don't know if there's some other best practice that others do in these cases.
Thanks in advance!
EDIT: Carl Manaster:
You're probably right. I think the problem is that most of the existing code base is very procedural. A lot of Windows services with a Run() method. I can definitely see how, if the project was structured a bit better, tests could be made with a lot more ease.
But let's say that the company can't invest in refactoring all of these existing projects. Should I just abandon the idea of unit testing these things?
If your methods are short enough, you should be able to mock only the interactions with one entity (Company), without interacting with the entities it returns. What you need is for your method to call (let's say) company.getDocument(). If your method under test has further interactions with the returned document at that point, split out that code, so that you can test that code's interactions with a (mocked) Document, without worrying about the Company in that test. It sounds as though your methods are currently much too long and involved for this kind of approach, but if you whittle away at them to the point where testing one method simply verifies that company.getDocument was called, you will find it much easier to test, much easier to work with, and ultimately much easier to understand.
Update
To your question of whether you should abandon the idea of unit testing: Do you want it to work? Do you have changes to make to the code? If the answers are (as I would assume) affirmative, then you should probably persevere. You don't have to test everything - but test what you're changing. You don't have to refactor everything - but refactor what you're working on so it's easier to test and easier to change. That "whittling away" that I mentioned: do that in service of solving the problems you have at the moment with your code base; over time you will find the code that most needed the tests has been tested - and it's a lot easier to work with because it's well tested and better factored.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Can someone please explain to me the Repository Pattern in .NET, step by step giving a very simple example or demo.
I know this is a very common question but so far I haven't found a satisfactory answer.
As a summary, I would describe the wider impact of the repository pattern. It allows all of your code to use objects without having to know how the objects are persisted. All of the knowledge of persistence, including mapping from tables to objects, is safely contained in the repository.
Very often, you will find SQL queries scattered in the codebase and when you come to add a column to a table you have to search code files to try and find usages of a table. The impact of the change is far-reaching.
With the repository pattern, you would only need to change one object and one repository. The impact is very small.
Perhaps it would help to think about why you would use the repository pattern. Here are some reasons:
You have a single place to make changes to your data access
You have a single place responsible for a set of tables (usually)
It is easy to replace a repository with a fake implementation for testing - so you don't need to have a database available to your unit tests
There are other benefits too, for example, if you were using MySQL and wanted to switch to SQL Server - but I have never actually seen this in practice!
This is a nice example: The Repository Pattern Example in C#
Basically, repository hides the details of how exactly the data is being fetched/persisted from/to the database. Under the covers:
for reading, it creates the query satisfying the supplied criteria and returns the result set
for writing, it issues the commands necessary to make the underlying persistence engine (e.g. an SQL database) save the data
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I see that people have ask more specific questions, but mine is broad, why should one test any routes at all? where does the benefit of this really shine? Thanks!
PS currently doing this in .Net C# MVC 3
Just my 2ยข to a very subjective question:
Because by unit testing your routes, a single key combination (that will run the unit tests) allows you to verify whether they behave as expected in contrast to running through your entire application and manually testing them by wasting enormous time and by potenatially forgetting to manually test some of the edge cases. Also when some other developer inherits the code base and starts modifying it, it is much easier for him to run this same key combination (that runs the unit tests) and get instant feedback whether his modifications didn't have some impact on the existing functionality rather than manually going through the entire application and clicking through all the links and stuff.
And from practical point of view I use MvcContrib TestHelper to unit test my routes.