3 ms·
> "Then you lose the ability to do unit testing without a database dependency" Not really, you just mock the database calls in the code you're unit testing.
by ZenoArrow 9y ago
> "Then you lose the ability to do unit testing without a database dependency"
Not really, you just mock the database calls in the code you're unit testing.
- scarface74 9y agoIf all of your business logic is in the stored procedures, what are you actually testing? And I realize that being able to test queries without database dependencies, only really applies to a few languages that treat queries as a first class citizen in the language like C# and Linq where you can mock out your actual Linq provider - replace the EF context with in memory List<T> - and still test your Linq queries.
- ZenoArrow 9y ago> "If all of your business logic is in the stored procedures, what are you actually testing?" Depends on what you want to test. Can either write unit tests for the stored procedures or unit tests for the code that makes use of those stored procedures.
- scarface74 9y agoAnd then when you write "unit tests" for stored procedures with a lot of developers you get slow "unit tests" that don't scale across multiple developers because of Comte toon issues.
- ZenoArrow 9y ago> "because of Comte toon issues" Qué?
- scarface74 9y agoDamn auto correct. That should have been "contention issues".
- spdionis 9y agoI think GP meant that you can't/it's hard to test the stored procedures themselves. In this case if you mock the database calls you will not test the database logic.
- ZenoArrow 9y agoYou can unit test stored procedures. For example, with T-SQL can use the open source unit testing framework tSQLt: http://tsqlt.org/ http://tsqlt.org/ tSQLt is used by the commercial SQL Test product from Red Gate if you wanted a more polished user experience: https://www.red-gate.com/products/sql-development/sql-test/index https://www.red-gate.com/products/sql-development/sql-test/i...