I would like to know what tools, patterns, etc people have used to be able to do TDD with CSLA .NET 3.8 and higher.
Which parts pose the most effort. Are there parts that are completely untested, etc.
Any and all information is most welcome.
Thanks
I use a combination of SpecFlow with xUnit to test my CSLA business objects. SpecFlow with xUnit are used to define and test the user scenarios (think: functional/acceptance testing), and xUnit alone is used to test individual classes and combinations of such.
Dependencies within the CSLA classes, such as data-access, are injected via a container. Such dependencies can and often are mocked for unit testing.
The test client and our remote Data Portal have separate containers loaded with the correct dependencies. If a test needs to mock any of the Data Portal dependencies we have a special CSLA Command that is executed (via xUnit BeforeAfterTestAttribute) on the Data Portal and replaces standard dependencies with our mocked dependencies. When the tests complete the Command is executed again to put the standard dependencies back into the container.
I hope some of this helps.
Related
I am not good at English. Please understand.
I knew. The use of #SpringBootTest() Annotation to load the entire Bean was clearly thought of as an "Integration Test."
However, the use of #SpringBootTest(classes=mybean.class) was thought to be "Unit Test" because it only runs a certain (selected) "Bean(Class)" although it runs a spring.
I also thought the way to use #ContextConfiguration" was also "Unit Tests." Because I thought only certain classes could be executed, such as #ContextConfusion(classes=myBean.class).
But it was my mistake. I received an answer to the last StackOverflow.
#SpringBootTest vs #ContextConfiguration vs #Import in Spring Boot Unit Test
My last question-->
Whether using #ContextConfiguration can be a "Unit Test"
$$$answer --->
No, it cannot, it's an integration test that runs only one class in spring.
Usually, we don't run only one class with Spring Framework. What is the benefit of running it inside the spring container if you only want to test the code of one class (a unit)? Yes, in some cases it can be a couple of classes, but not tens or hundreds.
If you run one class with spring then, in any case, you'll have to mock all its dependencies, the same can be done with mockito...
So I ask again.
Is "#WebMvcTest" also "Integration Tests"? I thought "#WebMvcTest" was the "Unit Test." However, based on the last answer, #WebMvcTest also has spring running. So the logic of the last answer is that "#WebMvcTest" is also "Integration Test," but I still don't understand.
I'm confused. Am I just playing with words?
Unit Test vs Integration Test...
Is the #WebMvcTest also an "Integration Test"?
Quote from Spring doc:
True unit tests typically run extremely quickly, as there is no
runtime infrastructure to set up. Emphasizing true unit tests as part
of your development methodology can boost your productivity.
Spring is also a kind of runtime infrastructure .So unit test should run without requiring to involve other frameworks even Spring.
Then it has the whole section to talk about Integration testing by introducing Spring TestContext Framework which it describes as :
The Spring Framework provides first-class support for integration
testing in the spring-test module. The name of the actual JAR file
might include the release version and might also be in the long
org.springframework.test form, depending on where you get it from (see
the section on Dependency Management for an explanation). This library
includes the org.springframework.test package, which contains valuable
classes for integration testing with a Spring container.
#ContextConfiguration is come from the Spring TestContext Framework while Spring Boot builds on top on it to provide #SpringBootTest and #WebMvcTest etc. So all these stuff are for Integation testing.
So to summarise, if a test requires starting up Spring in order to run such as #WebMvcTest , it is not a unit test but an integration test.
Firstly, some definitions taken from the Software testing fundamentals web site:
UNIT TESTING is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed.
INTEGRATION TESTING is a level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units.
To answer your question, the three annotations #SpringBootTest, #ContextConfiguration, and #WebMvcTest are all involved in loading a subset of Spring components. They are in consequence related to integration testing.
I'm building a web app in ruby, and it does all of it's data access through repositories. To make my unit tests fast, I also have in-memory versions of these repositories.
I would like the behaviour of these repositories to be identical, so it makes sense to use the same tests for both the real and in-memory repositories.
How would I go about doing this?
I am currently testing MVC 3 Controller and views using HTML and notepad. Is there other ways to do testing if you cannot modify the code? Like for example creating a seperate project to do testing?
Assuming that you have the capacity to create a test project or two which can tap into the web application, you essentially have to basic tools at your disposal:
Unit tests
Coded UI tests
Unit tests are used to test specific components of your application. If your application has a nice architecture which takes dependency injection into account, there is very little in MVC that you cannot unit test to some extent. The advantage of unit tests is that they help find the source of bugs in your code (as they are small, targeted tests) and that they help prevent regressions when refactoring or adding new functionality.
Coded UI tests are used to test user-facing features in your application and serve as integration tests which allow you to test the entire application stack, including the user interface. They are recorded just like you would record a macro in MS Office.
Both of these can be done nonintrusively. You'll need access to the original solution (or at least the DLLs and a hosted version of the website at the very least.
For more information on unit tests: http://msdn.microsoft.com/en-us/library/dd264975.aspx
For more information on Coded UI tests: http://msdn.microsoft.com/en-us/library/dd286726.aspx
I have some tests which are dependent on the success and failure of some tests. How can I define dependency as I am using VS2010 Mstest and selenium.
E.g
if test1 is failed then dont run test5, test 6. is this possible.
Unit Tests should always be isolated and completly non dependent on and thing else to run, not make non-fragile.
You could setup catagories with MSTest to seperate them into deferent logical structures.
A great book to find more details is this http://artofunittesting.com
Roy has also does alot of public speaking which is recorded online
Cheers
Tests shouldn't have dependencies between them.
If you have dependencies, then running them in a different order, or in isolation will cause them to fail sporadically - this can be very confusing for anyone else that is running the tests.
It's much better to define tests that setup their own data and assert something specific. You can use a mocking framework like Rhino Mocks to reduce the dependencies between modules of code by faking (mocking) areas that aren't relevant to your test. This is made much easier if you also use a dependency injection framework like Microsoft Unity as your code will have many more seams where mocking can be applied.
My Spring web project consists of:
util classes;
repositories;
services;
controllers.
The tests are as follows:
unit tests for util classes;
spring integration tests for repositories with HSQLDB;
unit tests for services with mock repositories;
unit tests for controllers with mock services.
There also may be system tests which test the overall project functionality. It can be performed with an external tool like Selenium or it can be performed using Spring integration testing.
The question is, should I include such spring integration system tests in a project or should they be separated somehow?
I see two problems about including system tests in a project:
1. they need configuration tuning because such tests will not run with production config (e.g. tests need a local datasource, not the one from JNDI);
2. they aren't autonomous, they need some external resources and so on. I cannot just run them as usual unit tests.
How do you organize your system testing?
On small projects I've kept them in the same place. On large enterprise projects (the kind for which you might usefully leverage Spring, for instance) we've usually organised system tests in a separate package / project. This helps keep them separate from the main codebase.
If you don't do this, there's all kinds of temptation to reuse classes from the code to "help out" in something which should be more strongly focused on the experience of users of the system (a user may be another system). If this happens, you end up with coupling between the project domain classes and the UI, which will have the inevitable effect of needing to duplicate much of the logic which helps keep them decoupled in the real codebase.
Most of the time the logic in system scenarios will actually be focused on pages, screens, web-calls, etc. so reusing code from the main project is a red herring. Keep the packages separate to avoid this happening, and because once you avoid it happening there's no need to have them in the same place.
Do, however, make sure that the system tests are checked in to the same version control as the code.
If you're not doing continuous integration and testing / deployment yet, that might be another area for which some learning will help you with the config files. That problem doesn't go away just because you have tests in a separate project, unfortunately.